Distribution: self-made Hardware Environment: Abit VP6 + Dual PIII Software Environment: Problem Description: Any kind of interrupts burst on the irq of eth0 (IRQ19) will disable the irq of the uhci usb controller (IRQ10). The reverse is also true. I think that somehow the irq of the PCI eth card and the integrated (on motherboard) usb controllers are still linked together. Steps to reproduce: # cat /proc/interrupts CPU0 CPU1 0: 326162 121 IO-APIC-edge timer 1: 1386 1 IO-APIC-edge i8042 8: 1 0 IO-APIC-edge rtc 9: 0 0 IO-APIC-level acpi 10: 204 1 IO-APIC-level uhci_hcd, uhci_hcd 12: 2367 0 IO-APIC-edge i8042 14: 14 0 IO-APIC-edge ide0 15: 12 2 IO-APIC-edge ide1 17: 0 0 IO-APIC-level EMU10K1 18: 1446 1 IO-APIC-level ide2, ide3, dc395x 19: 11 0 IO-APIC-level eth0 NMI: 0 0 LOC: 326112 326138 ERR: 0 MIS: 0 root@newshit [~] # ping -f 192.168.1.36 PING 192.168.1.36 (192.168.1.36): 56 octets data .irq 10: nobody cared! [<c0133de4>] __report_bad_irq+0x24/0x90 [<c0133ee1>] note_interrupt+0x61/0x90 [<c0133911>] __do_IRQ+0x121/0x130 [<c0104b26>] do_IRQ+0x46/0x70 ======================= [<c01006c0>] default_idle+0x0/0x40 [<c010321a>] common_interrupt+0x1a/0x20 [<c01006c0>] default_idle+0x0/0x40 [<c01006c0>] default_idle+0x0/0x40 [<c01006ed>] default_idle+0x2d/0x40 [<c010078a>] cpu_idle+0x4a/0x70 [<c02ee932>] start_kernel+0x162/0x1a0 [<c02ee370>] unknown_bootoption+0x0/0x1e0 handlers: [<f8fc6760>] (usb_hcd_irq+0x0/0x60 [usbcore]) [<f8fc6760>] (usb_hcd_irq+0x0/0x60 [usbcore]) Disabling IRQ #10 . Message from syslogd@newshit at Fri Nov 26 03:14:17 2004 ... newshit kernel: Disabling IRQ #10 . --- 192.168.1.36 ping statistics --- 148880 packets transmitted, 148879 packets received, 0% packet loss round-trip min/avg/max = 0.0/0.0/7.1 ms root@newshit [~] # cat /proc/interrupts CPU0 CPU1 0: 395181 121 IO-APIC-edge timer 1: 1576 1 IO-APIC-edge i8042 8: 1 0 IO-APIC-edge rtc 9: 0 0 IO-APIC-level acpi 10: 199999 1 IO-APIC-level uhci_hcd, uhci_hcd 12: 3570 0 IO-APIC-edge i8042 14: 14 0 IO-APIC-edge ide0 15: 12 2 IO-APIC-edge ide1 17: 0 0 IO-APIC-level EMU10K1 18: 1455 1 IO-APIC-level ide2, ide3, dc395x 19: 17313 280460 IO-APIC-level eth0 NMI: 0 0 LOC: 395137 395205 ERR: 0 MIS: 0
Created attachment 4143 [details] dmesg output with apic=verbose hope this will be helpfull note that I used a custom DSDT in this case. This is just the standard DSDT of my motherboard fixed to compile cleanly with iasl (only some Store(local0,local0) replace by noop basically). The problem is reproducible with the standard untouched DSDT from the bios also.
Created attachment 4144 [details] lsmod output don't know if that will be of any help?
Created attachment 4145 [details] /proc/config.gz no fancy stuff in the kernel config I think.
Created attachment 4146 [details] lspci -vvv
Please attach the acpidmp output. I'm curious why LINKD is still using with IOAPIC mode.
Created attachment 4147 [details] acpidmp as requested
Created attachment 4148 [details] details of the VP6 PCI/IRQ sharing assignments If that can help, this URL has a table with PIRQ/INT line/PCI slot assignement for my motherboard. For reference the ethernet card is currently sitting in slot PCI number 4.
From the DSDT, In PIC mode, 0c.0 and 07.2 use LNKD In IOAPIC mode, 0c.0 ->19, but 07.2 use LNKD->10 The symptom is 0c.0's IRQ and 07.2's IRQ possible bind together. Looks like some IRQ routing wrong. There is VIA quirk for IOAPIC.It route on-chip devices'IRQ to APIC. How about if you disable the quirk? Comments below line in drivers/pci/quirks.c: >DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_ioapic ); Guess VIA chipset datasheet will help us.
I tried your suggestion, but it didn't change anything to my problem. IRQ 10 still get disabled soon after I ping -f some other host on my network.
Created attachment 4151 [details] dmesg after disabling quirk_via_ioapic I don't see "PCI: Enabling Via external APIC routing" anymore.
The same PC booted with Win2k shows the same IRQ assignement EXCEPT for the USB controllers which are assigned or IRQ 7. I don't know any way of assesing how much interrupts goes through each irq with win2k, but generating network traffic + data transfer to usb storage does not seem to be a problem. Hope it can shed some light on my problem...
tested with 2.6.10-rc2-bk11 : same behavior.
What's the IRQ assignment with ACPI disabled?
Created attachment 4191 [details] /proc/interrupts with acpi=off as you can see with acpi=off, usb & eth share irq19. note that in that case I was not able to reproduce the problem. no more disabling irq xx because nobody cared.
Created attachment 4192 [details] dmesg with acpi=off for reference
Looks like eth and USB irq bind together. USB uses LNKD, but it's impossible to assign irq 19 to LNKD. Re comment 11: USB irq 7 and eth irq 19 in Win2k?
Hi David, I double checked and I confirm: Win2K SP4 assign IRQ7 to USB and IRQ19 to eth and it seems to work. MS black magic?
Dunno. USB did use LNKD, and LNKD has IRQ 10 according to ACPI. I didn't find any error in ACPI for your system.
same behavior with 2.6.10-rc3-bk2 + 2.6.10-rc3 ACPI patches from acpi.sf.net
same with 2.6.10?
yes it still happens with 2.6.10 I tested it with vanilla 2.6.10, 2.6.10-ac8 & 2.6.10-ac8 plus ACPI patches from acpi.sf.net for 2.6.10. Further development: I tried to reproduce the problem booting with the irqpoll parameter, the result is that it hard locks my box after less than 1 second of ping -f.
... and booting with irqfixup parameter does not make a difference, I lose IRQ10 after +- 10 seconds of ping -f.
long time since an update. but good news, the problem is finally fixed with stock 2.6.12-rc5 and: VIA 82C586B irq patch found at http://marc.theaimsgroup.com/?l=linux-kernel&m=111687820223338&w=4 and (possibly) ACPI VIA 686A/B PIC/APIC irq quirks patch found at http://sourceforge.net/mailarchive/forum.php?thread_id=7347269&forum_id=6102 I don't think the second patch is really needed but the first one is mandatory to have for motherboards with a 82C586B southbridge. Now I the two irq (eth and USB) are not linked anymore, and I cannot reproduce any IRQ xx: nobody cared errors. I did some heavy test, saturating the 100Mb eth card and doing multiple dd on USB storage devices, so I'm pretty confident that it's completely fixed. This patch is a must for me, any chance that it gets included in 2.6.12?
Tested with 2.6.12-rc5. Fixed now, I'm closing this