Bug 2870
Summary: | ATI: irq 5: nobody cared! - USB vs Sound - PIC mode - HP zx5000 | ||
---|---|---|---|
Product: | ACPI | Reporter: | Aditya Rajgarhia (adityar7) |
Component: | Config-Interrupts | Assignee: | Len Brown (lenb) |
Status: | REJECTED UNREPRODUCIBLE | ||
Severity: | high | CC: | acpi-bugzilla |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.9 [2.6.5 onwards] | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
Output of dmesg
Output of /proc/interrupts Output of lspci -vv "dmesg -s64000" from the failure case output from acpidmp dmesg for acpi=off /proc/interrupts from acpi=off cat /proc/interrupts |
Description
Aditya Rajgarhia
2004-06-11 08:34:04 UTC
If you are able boot an ACPI-enabled kernel, linux 2.6.9 or newer and you still see problems, then please re-open and attach (don't paste) the dmesg output (so that I can actually read it), and paste in the output from cat /proc/interrupts, and lspci -vv. Created attachment 4320 [details]
Output of dmesg
Created attachment 4321 [details]
Output of /proc/interrupts
Created attachment 4322 [details]
Output of lspci -vv
Tried on kernel 2.6.9 (Fedora Core 3) and get the IRQ problem when there is any sound. From what I've got in the last couple of days it disables IRQ 5, which is used by ndiswrapper for my wireless card. So I can't use the network anymore! Have attached output of dmesg, /proc/interrupts and lspci -vv as asked by Len Brown. IS there any temporary solution (patch or anything) until kernel is fixed? Do you think it'll fix temporarily if I remove alsa from the kernel? I need to use the network, please help!! It appears that atiixp sound device shares IRQ5 with the USB mouse. USB is enabled first. But just as atiixp is being enabled, USB on IRQ5 dies because it is receiving interrupts that it can't handle. If you wiggle the mouse, this allows the USB mouse to claim some of those interrupts on IRQ5 and thus survive. atiixp, in the meantime is erroneously looking for interrupts up on IRQ 10. Please attach the output from acpidmp, available in /usr/sbin or in pmtools here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ I can use this to confirm the interrupt mapping is correct, but based on the dmesg, it appears that Linux did not change the interrupt mapping from what the BIOS set up, so it looks good so far. Please disable the snd_printf(... atiixp: codec read timeout (...)" messages and re-collect the dmesg -s64000 from the failure case. Please attach the dmesg and /proc/interrupts from the "acpi=off" case. I expect they'll show atiixp on IRQ10, the question is if there is some sort of ATI quirk running to make that work. BTW. you may be able to get USB off of IRQ5 by adding cmdline parameter "acpi_irq_isa=5" and "acpi_irq_balance" -- but that would be a workaround hiding the bug rather than a fix. Created attachment 4352 [details]
"dmesg -s64000" from the failure case
Created attachment 4353 [details]
output from acpidmp
Created attachment 4354 [details]
dmesg for acpi=off
Created attachment 4355 [details]
/proc/interrupts from acpi=off
Len: I've attached everything you wanted. For the dmesg (failure case) I did not know how to disble the snd_printf() and could not find out how to do it. If you still need it then please tell how to disable it. Hopefully you can fix it. Last few days I've got several people replying to my thread in a forum, these people with atiixp all having the same problem. I'll try the workaround now. Tried the workaround cmdline parameters you gave. Now according to /proc/interrupts the USB has been removed from IRQ 5. The dmesg no longer complaints about screaming IRQs. However, the mouse wiggling has become much worse. In fact without the workaround, in 2.6.9 I don't rally need to wiggle the mouse but it would bring down the network. Tell me if you need any outputs from the workaround case. Thanks. Did you enable IOAPIC (select config APIC and IOAPIC) make your system work? Turned on IOAPIC and have not been able to recreate error last few days, so it must have fixed the IRQ problem! Anyway I have attached the output of /proc/interrupts if anyone wants to have a look. Thanks for the fix, David Shaohua!! Created attachment 4420 [details]
cat /proc/interrupts
looks like enabling the IOAPIC fixed the problem. Fortunately, almost all the distros enable the IOAPIC these days. Please re-open if you want to debug the PIC-mode failure or if you have a problem with 2.6.22.stable or later. unrelated to the issue in this bug report, but of historical, or perhaps academic, significance... the DSDT for this HP zx5000 laptop implements the optional ACPI 2.0 _GTS (Going to Sleep) method: Method (_GTS, 1, NotSerialized) { Store (0x01, \_SB.PCI0.LPC0.PWSC) Store (0x00, \_SB.PCI0.LPC0.EC0.THEN) Store (0x00, \_SB.PCI0.LPC0.EC0.DUTY) If (LEqual (Arg0, 0x03)) { Store (0x01, \_SB.PCI0.P2P.USB0.USS0) Store (0x01, \_SB.PCI0.P2P.USB1.USS1) Store (0x01, \_SB.PCI0.P2P.USB2.USS2) } } ...which appears to tickle some ATI chipset registers on entry to suspend. Curiously, the DSDT does not implement a matching _BFS method. This is the 1st implementation of _GTS I've seen. |