Re: emu10k1 - interrupt storm?

[Rui Sousa]

On 11 Dec 2001, Zlatko Calusic wrote:

> Rui Sousa <[e-mail]> 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