The other kind of dmesg errors that you get is like this:
Code:
include/asm/dma-mapping.h:132 AosMemoryFreePhysical+0xf5/0x144 [nvsound]()
Hardware name: A7N8X-E
Modules linked in: nvsound(P) nvidia(P) sg parport_pc parport nvidia_agp soundcore agpgart [last unloaded: nvsound]
Pid: 10817, comm: firefox Tainted: P W 2.6.31-gentoo #1
Call Trace:
[<c101c3a2>] ? warn_slowpath_common+0x5e/0x8a
[<c101c3d8>] ? warn_slowpath_null+0xa/0xc
[<e26a554e>] ? AosMemoryFreePhysical+0xf5/0x144 [nvsound]
[<e2652050>] ? _ZN8CNvVoiceD0Ev+0x160/0x168 [nvsound]
[<e26023ec>] ? _ZdlPv+0x38/0x50 [nvsound]
[<e2642940>] ? _ZN9CNvStreamD0Ev+0x1c0/0x1c8 [nvsound]
[<e26465f1>] ? _ZN9CNvStream12FinalReleaseEv+0x57/0x68 [nvsound]
[<e2602c20>] ? _ZN10NvaUnknown20NondelegatingReleaseEv+0x36/0x48 [nvsound]
[<e269accb>] ? _ZN9CNvStream7ReleaseEv+0x17/0x1c [nvsound]
[<e268e0ad>] ? _ZN13CApuStreamPciD0Ev+0x47/0xd6 [nvsound]
[<e2602c20>] ? _ZN10NvaUnknown20NondelegatingReleaseEv+0x36/0x48 [nvsound]
[<e269be53>] ? _ZN13CApuStreamPci7ReleaseEv+0x17/0x1c [nvsound]
[<e2688098>] ? Nv_FreeNewstream+0x2c/0x38 [nvsound]
[<e26a6d5e>] ? Nvfree_wave_device+0x55/0x123 [nvsound]
[<e26a6f21>] ? Nvaudio_release+0xf5/0x106 [nvsound]
[<c1065fed>] ? __fput+0xc0/0x17a
[<c1063672>] ? filp_close+0x4e/0x54
[<c10636e5>] ? sys_close+0x6d/0xb7
[<c10027f4>] ? sysenter_do_call+0x12/0x26
---[ end trace 94f160b26cd3b606 ]---
It is different from the one I gave in the previous post. This is just a warning and it doesn't do anything pro-actively. I tried to find out what is giving such warnings and it seems this has to do with some assembly code in the nvsound sources. I am not much of a programmer, so fixing this is completely beyond my reach.
The patch I gave in my earlier post has been working pretty fine till now
Without the patch above, you can run the following in the terminal to detect when your sound gets corrupted:
Code:
while ! dmesg | grep -w '21'; do
sleep 10
done;
Essentially, what is happening is that IRQ_HANDLED and IRQ_NONE are defined as enums in the newer kernels (see
/usr/src/linux/include/linux/irqreturn.h). In the nvsound sources, these are redefined into some weird hexadecimal numbers. If you read the kernel sources, you will come across this comment in
/usr/src/linux/kernel/irq/spurious.c
Code:
/*
* If 99,900 of the previous 100,000 interrupts have not been handled
* then assume that the IRQ is stuck in some manner. Drop a diagnostic
* and try to turn the IRQ off.
*
* (The other 100-of-100,000 interrupts may have been a correctly
* functioning device sharing an IRQ with the failing one)
*
* Called under desc->lock
*/
So, the kernel waits till it has received more than 99,900 bogus IRQ_HANDLED or IRQ_NONE, and then it disables the IRQ. That is when the sound gets "choppy" or full of "static". This is what my patch tries to fix.
Bookmarks