Distribution: Gentoo Hardware Environment: Athlon XP + nforce2 on chaintech 7nif2 Software Environment: Problem Description: On bootup IRQ of the sound chip is disabled, thus no sound. Steps to reproduce:
Created attachment 2247 [details] dmesg
Created attachment 2248 [details] acpidmp
Created attachment 2249 [details] dmidecode
Created attachment 2250 [details] /proc/interupts
Created attachment 2251 [details] /proc/interupts no-acpi
Created attachment 2252 [details] lspci -vv
please try disable CONFIG_PCI_USE_VECTOR. do your EHCI controller work in acpi mode or nonacpi mode?
i disabled CONFIG_CPI_USE_VECTOR here is the relevant section of dmesg: irq 21: nobody cared! Call Trace: [<c010b83a>] __report_bad_irq+0x2a/0x90 [<c010b930>] note_interrupt+0x70/0xb0 [<c010bc20>] do_IRQ+0x130/0x140 [<c0107030>] default_idle+0x0/0x30 [<c0105000>] _stext+0x0/0x60 [<c0109e08>] common_interrupt+0x18/0x20 [<c0107030>] default_idle+0x0/0x30 [<c0105000>] _stext+0x0/0x60 [<c0107054>] default_idle+0x24/0x30 [<c01070d0>] cpu_idle+0x30/0x40 [<c03a86fc>] start_kernel+0x14c/0x160 [<c03a8460>] unknown_bootoption+0x0/0x110 handlers: [<e1907850>] (snd_intel8x0_interrupt+0x0/0x210 [snd_intel8x0]) Disabling IRQ #21 /proc/interupts : 0: 570288 XT-PIC timer 1: 1467 IO-APIC-edge i8042 2: 0 XT-PIC cascade 8: 2 IO-APIC-edge rtc 9: 0 IO-APIC-level acpi 14: 10683 IO-APIC-edge ide0 15: 42 IO-APIC-edge ide1 19: 42663 IO-APIC-level <NULL> 20: 59024 IO-APIC-level ohci_hcd, eth0 21: 152238 IO-APIC-level NVidia nForce2 22: 50125 IO-APIC-level ohci_hcd with acpi=off kernel parameter audio works (somewhat)
This looks more like an audio bug than an ACPI bug. Does audio work properly when you boot with "noapic" (note spelling). > ACPI: PCI Interrupt Link [APCL] enabled at IRQ 21 > IOAPIC[0]: Set PCI routing entry (2-21 -> 0xc1 -> IRQ 21 Mode:1 Active:0) > 00:00:02[C] -> 2-21 -> IRQ 193 active:0 means polarity HIGH. Curiously, all the PCI interrupts on this box are marked that way, which is somewhat unusual. No problems with eth0 or USB? 177: 26235 IO-APIC-level ohci_hcd, eth0 185: 20652 IO-APIC-level ohci_hcd 193: 152282 IO-APIC-level NVidia nForce2 225: 467 IO-APIC-level <NULL> the IRQ was shut down after 99900/152282 interrupts on this IRQ were not claimed by the driver. If ACPI set the polarity incorrectly, then this would have fired at 100000 interrupts -- ie a completely quiescent device would have caused an interrupt storm. This suggest that either the device itself has an issue, or that there is something funky on this board with that interrupt line being pulled by a device that Linux does not have on that IRQ. lspci shows that EHCI is on this IRQ as well. Perhaps you can load the EHCI driver and not the sound driver and see if it handles any interrupts? I'm curious why the snd_intel8x0 driver is handling interrupts for a device called "NVidia nForce2" -- maybe that is part of the problem? So this may have nothing to do with ACPI. Except that ACPI is the only way to enable the IOAPIC on this box. You can run with ACPI and without the IOAPIC by booting an ACPI-enabled kernel with "noapic". I'm curious if in both apic and "noapic" modes if your ACPI interrupt is working properly -- you should see it increment in /proc/interrupts when you press the power button. (first "/sbin/inti.d/acpid stop" to make sure it doesn't shut down your machine. Can you attach your .config? I have a similar machine I may be able to try. it would also be interesting if the system functions properly when you boot in IOAPIC mode with "noirqdebug" this will disable the nobody cared shutdown of the IRQ. Should not harm other devices b/c the IRQ is dedicated to this device. Observing the rate of change for audio interrupts in /proc/interrupts may show if some particular action is cauting a burst of un-claimed interrupts.
Generaly this box is quite a nuissance. I'll be damned if i ever go for chaintech again. > This looks more like an audio bug than an ACPI bug. > Does audio work properly when you boot with "noapic" (note spelling). Yes. I'm not very handy with alsa, oss emulation doesn't work with xmms, but mplayer seems to sucessfully find sound device and play on it. > which is somewhat unusual. No problems with eth0 or USB? I think forcedeth (reverse engineered driver for nvidia network adapter) halts the system every now and then. I have no proof that it's this particular driver, the only thing to it, is that i've ran the system for ~24 hours without that module and it didn't crash, while with it, usually doesn't survive for more then 12 hours. I don't see anything in the log even with sysrq+t. I have one USB device - wacom drawing pad, and the cursor on it shakes even when the mouse is perfectly still. This is probably more of chosing correct sensitivity level, rather than IRQ issue. > completely quiescent device would have caused an interrupt storm. This > suggest that either the > device itself has an issue, or that there is something funky on this board > with that interrupt line being pulled by a device that Linux does not have on > that IRQ. I don't know, but with the amout of trouble this board is causing me it can be antything. ;) > I'm curious why the snd_intel8x0 driver is handling interrupts for a device > called "NVidia nForce2" > -- maybe that is part of the problem? I think this is alight though, NVidia nForce2 (Audio) is what it is. Have a look at the attached "/proc/interupts no-acpi" file > So this may have nothing to do with ACPI. Except that ACPI is the only way to > enable the IOAPIC on this box. You can run with ACPI and without the IOAPIC > by booting an ACPI-enabled kernel with "noapic". I'll run for a while with "noapic" see how that feels. (at least audio works like that) > I'm curious if in both apic and "noapic" modes if your ACPI interrupt is > working properly -- you should see it increment in /proc/interrupts when you > press the power button. (first "/sbin/inti.d/acpid stop" to make sure it > doesn't shut down your machine. Now i can't seem to get any signals from the power button with "noapic" or without it. But I remeber that once upon a time i've had it working, and i could see stuff comming out of /proc/acpi/events. Can't remeber what i changed since then. If it's important i can spend some time on it. > Can you attach your .config? I have a similar machine I may be able to try. Will do. Though i'm afraid it's this particular board that's messed up. It's a mini-ATX, btw. I'll also post /proc/interupts for noapic, just in case.
Created attachment 2272 [details] /proc/interupts noapic
Created attachment 2273 [details] /usr/src/linux/.config
*** This bug has been marked as a duplicate of 2574 ***