Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 12 Dec 2001 05:27:29 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 12 Dec 2001 05:27:19 -0500 Received: from cnxt10002.conexant.com ([198.62.10.2]:29068 "EHLO sophia-sousar2.nice.mindspeed.com") by vger.kernel.org with ESMTP id ; Wed, 12 Dec 2001 05:27:09 -0500 Date: Wed, 12 Dec 2001 11:26:47 +0100 (CET) From: Rui Sousa X-X-Sender: To: Zlatko Calusic cc: , Subject: Re: emu10k1 - interrupt storm? In-Reply-To: <87ofl534o2.fsf@atlas.iskon.hr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On 11 Dec 2001, Zlatko Calusic wrote: > Rui Sousa writes: > > > On 9 Dec 2001, Zlatko Calusic wrote: > > > > The emu10k1 only generates interrupts when playing pcm sound. > > The interrupt rate depends on the "fragment" size and is usually > > smaller than ~1000interrupts/s (this is 256bytes fragment 48Khz sample > > rate, 16bit, stereo). > > > > Is it possible there is another device producing these interrupts? > > On-board devices (usb, ...) that you don't use? > > Does this happen with this kernel only? > > Hm, looks like it is really emu10k1. But... > > When I booted into single user mode, the kernel wasn't reporting > interrupts. Then I started Gnome, and there they were. Finally I found > that killing/starting esd changes things. Whenever esd was up, > interrupts were generated, when I killed it interrupts would stop. Ok. Esd usually uses very small fragment sizes (~256 bytes) which cause high interrupt rates. > > Then I straced esd daemon, just to find it was blocked on select(). > > {atlas} [~]# strace -p 705 > select(12, [4 6 7 8 9 10 11], NULL, NULL, NULL > > Strange, if esd is not doing any work (just sleeping) who generates > interrupts then? If the sound device is open and playback is enabled the driver runs at "full speed" even if the output is just silence. > Also, we don't know now is it the driver to blame, or silly esd daemon. Both I think... With some machines the hardware timer(used inside the emu10k1) seems to be running at wrong rate. > > > > Which functions do you see listed? If it's only "emu10k1_interrupt()" > > then the interrupt was not generated by the emu10k1. > > > > Top 5 entries in the kernel profile: > > 475 __rdtsc_delay 16.9643 > 309 handle_IRQ_event 2.4919 > 178 do_softirq 0.8725 > 148 emu10k1_waveout_bh 0.7872 > 135 emu10k1_interrupt 0.6490 > > As time goes by, the numbers get bigger (that is only 15min after > reboot)... > > Maybe it's time to enable debug option in the driver? Yes. Start by checking the audio format used (sample bytes, sample rate, channels) and buffering parameters (fragment size). The interrupt rate is: fragment_size / ( sample_rate * sample_bytes * channels) irq/s Also if the timer rate is screwed up you should see a lot of (from emu10k1_waveout_bh() in audio.c) DPD(3, "Not enough transfer size -> %d\n", bytestocopy); going like 64, 128, 192, 64, 128, 192 if for example you have a fragment of 256 bytes and the clock rate is 4 times what it should. > Sorry for late answer, I got busy yesterday... > Rui Sousa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/