ACPI PCI routing problem

Andrew de Quincey
2003-07-10T23:22:29Z

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.