lkml.org 
[lkml]   [2001]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: emu10k1 - interrupt storm?
On 11 Dec 2001, Zlatko Calusic wrote:

> Rui Sousa <rui.p.m.sousa@clix.pt> 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/

\
 
 \ /
  Last update: 2005-03-22 13:18    [W:0.103 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site