Most recent kernel where this bug did *NOT* occur: 2.6.16 (not tested between 2.6.16 and 2.6.19) Distribution: Debian but it's my own kernel not from Debian. Hardware Environment: -motherboard: A7V600-X-EAYKZ -CPU: AMD Duron 750Mhz Software Environment: Same problem with 2.6.19 and 2.6.19.1 Problem Description: On boot, this message is printed: > irq9: nobody cared (try booting with the "irqpoll" option). I have no problem with the 2.6.16 and I have not changed the ACPI options. With 2.6.19 I have tried the irqpoll option and the bug appeared also but I don't remember if it's later or not; because I also tryed to revert the patch as described in #7601, and in one case the "irqn: nobody cared" appaered later.
Created attachment 9845 [details] lspci with 2.6.16 lspci output with 2.6.16
Created attachment 9846 [details] cat /proc/interrupts with 2.6.16
Created attachment 9847 [details] screenshot 1 or acpi infos, before the fatal error message
Created attachment 9848 [details] screenshot 2, the error message
Created attachment 9849 [details] screenshot 3, just after the error message
Created attachment 9850 [details] after, the kernel loop on this message
Created attachment 9851 [details] acpidump
Created attachment 9852 [details] acpidump with 2.6.16
Created attachment 9853 [details] config of the 2.6.19.1 kernel
Please attach the full dmesg -s64000 (or serial console log with "debug" enabled)and /proc/interrupts of the latest working kernel, and the first failing kernel (failing kernel will need irqpoll to boot) Confused about the comment regarding reverting patch in bug #7601 -- as that patch is already reverted in 2.6.19.1 -- it appeared only in 2.6.19. acpidump shows that this machine has an IOAPIC: ACPI: APIC (v001 ASUS A7V600-X 0x42302e31 MSFT 0x31313031) @ 0x(nil) ACPI: IOAPIC (id[0x02] address[0xfec00000] global_irq_base[0x0]) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Length 90 OK Checksum OK however, the 2.6.16 /proc/interrupts shows PIC mode is being used, and the config for 2.6.19.1 suggests that it isn't being used there either. While this appears to be a PIC-mode regression, and worthy of being debugged, it would also be interesting to try IOAPIC mode on the old and new kernel as well -- simple to enble this with CONFIG_SMP. As IOAPIC mode is preferable if it works. The MADT shows that the APIC-mode entries are all hard-coded so from an ACPI point of view, it should be very simple and reliable -- and the only obstacle might be the dreaded VIA quirk.
Created attachment 9892 [details] 2.6.19.1 success on KT400 box - dmesg I dug up a KT400 box to see if I could reproduce this failure, but it works for me. 00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8235 PCI Bridge 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) 00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50) 00:13.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 Pro Ultra TF CPU0 0: 49914 XT-PIC-XT timer 1: 10 XT-PIC-XT i8042 2: 0 XT-PIC-XT cascade 4: 736 XT-PIC-XT serial 6: 5 XT-PIC-XT floppy 7: 121 XT-PIC-XT parport0 8: 0 XT-PIC-XT rtc 9: 0 XT-PIC-XT acpi 10: 0 XT-PIC-XT uhci_hcd:usb1, uhci_hcd:usb2 11: 3419 XT-PIC-XT uhci_hcd:usb3, VIA8233, ehci_hcd:usb4, eth0 12: 131 XT-PIC-XT i8042 14: 4431 XT-PIC-XT ide0 15: 1569 XT-PIC-XT ide1 NMI: 0 LOC: 49850 ERR: 97 MIS: 0 (It also works fine in IOAPIC mode) CPU0 0: 8589 IO-APIC-edge timer 1: 8 IO-APIC-edge i8042 4: 352 IO-APIC-edge serial 6: 5 IO-APIC-edge floppy 7: 0 IO-APIC-edge parport0 8: 0 IO-APIC-edge rtc 9: 0 IO-APIC-fasteoi acpi 12: 131 IO-APIC-edge i8042 14: 3140 IO-APIC-edge ide0 15: 92 IO-APIC-edge ide1 16: 272 IO-APIC-fasteoi eth0 18: 0 IO-APIC-fasteoi uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, ehci_hcd:usb4 19: 0 IO-APIC-fasteoi VIA8233 NMI: 0 LOC: 8515 ERR: 0 MIS: 0
> ERR: 97 This is from: > spurious 8259A interrupt: IRQ7. And have been present as long as I've had this board. It is the motherboard's way of telling the OS to use IOAPIC mode instead of PIC mode:-) Any progress identifying the latest working and first failing kernel on the A7V600-X-EAYKZ, per comment #10?
Created attachment 9894 [details] dmessage for kernel 2.6.17 which have the problem Compiled with debug, the config for this kernel is following. So the kernel 2.6.16 is working and not the 2.6.17. I have not check with kernel 2.6.17.rc* or 2.6.16.*, do you want that I check these kernels too ? >Confused about the comment regarding reverting patch in bug #7601 -- >as that patch is already reverted in 2.6.19.1 -- it appeared only >in 2.6.19. the reverting patch was applied on 2.6.19
Created attachment 9895 [details] The kernel config file of the 2.6.17
Comment on attachment 9894 [details] dmessage for kernel 2.6.17 which have the problem 2.6.36 has not the problem so 2.6.17 is the first with the problem. It's compiled with the debug option.
lsppci: 0000:00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) dmesg: VP_IDE: IDE controller at PCI slot 0000:00:0f.1 ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 9 PCI: setting IRQ 9 as level-triggered ACPI: PCI Interrupt 0000:00:0f.1[A] -> Link [LNKE] -> GSI 9 (level, low) -> IRQ 9 PCI: VIA IRQ fixup for 0000:00:0f.1, from 14 to 9 Please attach the output from lspci -vv (running on any release) so I can verify that IDE at 0000:00:0f.1 is indeed associated with LNKE. Last time I checked, IDE was hard-coded to IRQ14, so if the hardware is trying to route this to IRQ9, it makes perfect sense that when IDE starts it nukes ACPI, which can't handle the spurious interrupts on IRQ9.
Created attachment 11002 [details] 2.6.21-rc5 patch to remove irq compression > 2.6.17 is the first with the problem Interesting. That is when "irq compression" was added. Please reproduce the issue with the latest kernel -- 2.6.21-rc5 and then apply the this patch to remove irq compression and re-test.
please re-open if this issue is still present in 2.6.22.stable or later