ACPI PCI routing problem

[Andrew de Quincey <adq_dvb-fmPXVN3awWJAJAzL26g0SA@public.gmane.org>]

Hi, I have an Epox 8RDA+ NForce2-based motherboard (uniprocessor, Athlon XP). 
This board has an IO-APIC with 0x17 pins. I can't tell you much more specific 
about it, as it is in the nforce2 chipset to which I do not have docs. I'm 
using kernel 2.5.74, with APIC, IO-APIC, ACPI turned on. 

First of all, here are the symptoms:

Kernel boots OK, devices with IRQs <=15 are fine. However, the system attempts 
to allocate some devices (e.g. USB) to IRQs 20 and 21, as told by the AML 
code in my BIOS (more on this later).

The USB busses do not work. The devices are detected, but all attempts to send 
USB packets time out. Examining /proc/interrupts shows the reason: IRQ21 has 
had MILLIONS of spurious interrupts. It is receiving them even before the USB 
driver starts, so the kernel detected that no driver is registered, and 
disabled the IRQ (in arch/i386/kernel/irq.c). It prints "IRQ 21:nobody 
cared".

The other USB bus just seems to receive no interrupts at all.

If I pass pci=noapci as a kernel parameter, everything works (USB busses are 
allocated to IRQs <=15), but I thought I would take the time to debug this 
issue properly. Also, it gave me an excuse to learn about ACPI and APICs :)

The PCI Interrupt Link names for my USB devices are APCF, APCG respectively. 
Here is the output from the ACPI PRT parsing code during kernel bootup:

pci_link-0256 [39] acpi_pci_link_get_curr: No IRQ resource found
ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22, disabled)
pci_link-0256 [41] acpi_pci_link_get_curr: No IRQ resource found
ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22, disabled)

I have decompiled the AML code in my BIOS to verify that the ACPI parser is 
functioning correctly. It is.

During the initialisation of the IO-APIC (and the parsing of the MADT ACPI 
table), the following is printed:
 IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not 
connected.

Heres my problem: is this a bug in my BIOS's ACPI tables, or a bug in the 
kernel. The "not connected" stuff above kinda implies that the PRT 
information is duff.. but I'm not sure what "not connected" means here... 
does it mean physically unconnected, or just logically?

From the ACPI spec, I got the impression that the MADT table contains 
overrides for the *8539 PIC* IRQs.. so you wouldn't get IRQs > 15 in there 
anyway.

If this is a BIOS bug, I'll probably develop a patch which warns when duff PRT 
tables are present, and forces pci=noacpi. 

If this is a kernel bug, can anyone suggest where to go next. I can provide 
more information if necessary...

Incidentally, this only started in kernel 2.5.63 (or very close to there) when 
a bug was fixed in the ACPI parser when a device does not have an IRQ 
allocated already (The "No IRQ resource found" printout above). Prior to 
this, I think the PRT parser just bombed out completely, and the system used 
some other IRQ routing method.



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1