Distribution: Hardware Environment: Software Environment: Problem Description: Steps to reproduce:
Created attachment 762 [details] dmesg and acpidmp
Created attachment 764 [details] dmesg booting with acpi
Distro: Gentoo Hardware Environment: Asus P4T533-C Intel P4 2.4 GHz 3Com 3c905B NIC Adaptec AIC-7892A U160/m (rev 02) etc.. Software Env: Kernel: vanilla 2.4.22 / 2.6.0-testX Problem Description: #1: High interrupt rate: After 11:43:53 up 12 min, 0 users, load average: 0.32, 0.63, 0.39 CPU0 0: 73491 IO-APIC-edge timer 1: 3783 IO-APIC-edge keyboard 2: 0 XT-PIC cascade 8: 2 IO-APIC-edge rtc 9: 2 IO-APIC-edge eth0 14: 919 IO-APIC-edge ide0 15: 9 IO-APIC-edge ide1 20: 11779 IO-APIC-level aic7xxx 22: 60376810 IO-APIC-level acpi NMI: 0 LOC: 73449 ERR: 0 MIS: 0 This high interrupt rate slowdowns the box noticeable. #2 eth0 doesn't work if acpi enabled. See attached dmesg #3 When I type pci=noacpi on lilo prompt then I can't boot the machine. It hangs while detecting the scsi drives on aic7xxx.
Hmmm, ACPI taking zillion interrupts on IRQ22 and eth0 taking none on IRQ9.... FADT (byte offset 46) specifies that the ACPI SCI comes in on PIC IRQ 9. MADT, however, over-rides this and maps IRQ9 to IRQ22 in IO-APIC mode: > ACPI: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x16] polarity[0x3] trigger [0x3]) But then: > PCI: No IRQ known for interrupt pin A of device 02:0a.0 If this is eth0, it is unclear how it got here, and how it ended up on IRQ 9. Can you attach the output from lspci -vv? I assume the devices work if you force PIC mode and boot with cmdline "noapic"?
Please try patch for bug #774, I want to see what could happen, if irq for SCI gets changed.
Created attachment 796 [details] lspci in APIC mode without acpi
Created attachment 797 [details] /proc/interrupts with acpi enabled in PIC mode
When I boot with noapic it works with and without acpi. In PIC mode there is a different IRQ routing with and without acpi. attached as requested lspci (apic) and /proc/interrupts in PIC mode I will try the SCI patch in a few minutes...
> 02:0a.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev > 34) > Interrupt: pin A routed to IRQ 22 I think that you're getting an eth0 interrupt on IRQ22, but eth0 is not there to handle it, and acpi can't, so it never goes away. Assuming that IRQ22 is PIRQG, then your NIC would be in slot 2 -- which shares interrupts with USB and Promise. I expect that USB and Promise don't work either;-O I expect that if you move your NIC to another slot, that it will work. The question is why eth0 ended up on IRQ9. Please add CONFIG_ACPI_DEBUG to the failing configuration and perhaps dmesg will tell us why. I suspect we have a bug when the board is wired to share SCI with a PCI device on the same IRQ in IO-APIC mode.
Created attachment 798 [details] dmesg with SCI patch Yo, it seems to works with the SCI patch. A question: Why do you assign interrupt 11 statically to acpi? Can't it assigned dynamically? What happens if irq 11 assigned to a device? Conflict? Interrupt sharing?
Created attachment 799 [details] /proc/interrupts with usb nvidia etc... No you are wrong luckily;-) All things are working USB NVIDIA etc... What i don't have tested is the isdn card...but I think it will work too.. Should I test "CONFIG_ACPI_DEBUG" with the SCI patch applied?
Where do you see promise? I think I don't have such shity hardware...;-) And I can't test NIC in another slot, all are full:-( What I have tried a long time ago, is to find out the best combination with the cards, so that nothing shares an irq with another device...
Created attachment 803 [details] dmesg with CONFIG_ACPI_DEBUG on I had to take the messages from /var/log/messages because the dmesg buffer was to short. I hope there are all infos too
Sep 3 12:17:21 hdg kernel: pci_irq-0302 [17] acpi_pci_irq_derive : Unable to derive IRQ for device 02:0a.0 Sep 3 12:17:21 hdg kernel: PCI: No IRQ known for interrupt pin A of device 02:0a.0 Sep 3 12:17:21 hdg kernel: pci_irq-0302 [16] acpi_pci_irq_derive : Unable to derive IRQ for device 02:0a.0 Sep 3 12:17:21 hdg kernel: PCI: No IRQ known for interrupt pin A of device 02:0a.0 may need to add some debug code to get to the cause. I'm not positive that /var/log/messags gets everything. note that dmesg with a size argument, say dmesg -s 40000 may get back to the beginning. BTW. I found Promise on PIRQG on the interrupt table in the ASUS P4T533 user manual. Shares an interrupt with PCI slot 2 and the USB 2.0. Maybe Promise is a MB option. http://www.asus.com/pub/ASUS/mb/sock478/p4t533/e1109_p4t533.pdf
Created attachment 806 [details] right dmesg but cutted Len, notice I have P4T533-C. There are little differences between them. I know "dmesg -s". I tried it with factors of ten. Perhaps it was too much...:-/ Anyway, I will wait with further testing until you sent me the patch with more debug code, which you mentioned. Thank you
can you try this: add below lines with '/****/' into routine 'mp_parse_prt' of file 'mpparse.c' /* Don't set up the ACPI SCI because it's already set up */ if (acpi_fadt.sci_int == irq) { /*****/ entry->irq = irq; /*we still need to set entry's irq*/ /********/ continue; } /*****/
Created attachment 818 [details] IRQ routing with entry->irq set This seems to work. No problem yet. If you need full dmesg I will attach it.
yes, if you can attach the full dmesg resulting from applying just shaohua's patch, we can probably put this one to bed. thanks.
Created attachment 904 [details] dmesg entry->irq set