Recent interrupt craziness after S3 resume with ens1371.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi guys

I have a recent interrupt rate issue with an old Soundblaster card of
mine.

More specifically, I run Debian Lenny with a custom tickless kernel on a
E6600 Core 2 Duo / MSI P965 Platinum Mobo system. During recent months,
I've been keeping up with stable kernel releases most of the time, went
through the whole 2.6.25 stable releases and upgraded to 2.6.26.2 (now
3) about a week ago.

$ uname -a
Linux gigli 2.6.26.3 #1 SMP PREEMPT Fri Aug 22 10:43:41 CEST 2008 i686 GNU/Linux


In that system, I have an old Soundblaster card I bought more than 10
years ago, the model of which I unfortunately don't remember. I just
keep it around since it has 2 DAC chips which come in handy at times.

$ lspci -vx
05:01.0 Multimedia audio controller: Ensoniq 5880 AudioPCI (rev 02)
        Subsystem: Ensoniq Device 2000
        Flags: bus master, slow devsel, latency 64, IRQ 17
        I/O ports at ec00 [size=64]
        Capabilities: <access denied>
        Kernel driver in use: ENS1371
        Kernel modules: snd-ens1371
00: 74 12 80 58 05 00 10 14 02 00 01 04 00 40 00 00
10: 01 ec 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 74 12 00 20
30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 0c 80


Now, the issue I'm recently having is that when I resume the system from
RAM suspend the interrupt rates on that card are just crazy, usually
around 22k. Albeit the interrupt being shared, I know it's the
card/driver because un/reloading snd_ens1371 consistently puts the
system back to normal.

$ cat /proc/interrupts
 17:    8109127          0   IO-APIC-fasteoi   eth1, Ensoniq AudioPCI


Now, I didn't have this issue usually. Unfortunately, I can't recall
when exactly it was introduced, but it's at most 6 weeks ago and I
believe it was at one of the last stable 2.6.25 releases. It persisted
since then, including the now running 2.6.26.3.

My question hence, how should I best proceed on this issue? Shutting all
sound apps down to reload the driver is just too awksome, as it partly
defeats the purpose of suspend to RAM and also since all worked well
until recently.

Sould I further debug it, and if so how? Or should I file a bug on the
alsa or kernel list ... ?

Thanks for advice, Raimund

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Alsa-user mailing list
Alsa-user@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-user

[Index of Archives]     [ALSA Devel]     [Linux Audio Users]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]

  Powered by Linux