Hey folks, After looking at Intel docs for the last several days I've uncovered what may be the source of our interrupt aliasing problem. In order to support non-APIC mode operation, IOAPICs servicing other PCI busses than the primary in the system support so-called "boot interrupt" operation. In this mode (which is enabled by default) if they receive an interrupt and it is masked in the IOAPIC (again the default), it will trigger the boot interrupt signal instead. This signal is usually a dedicated pin on the bridge and is attached to the IOAPIC in the ICH that also gets the ISA interrupts from the 8259s. In the Intel WV2 board, the boot interrupt line from the P64H2 PCI-PCI bridge is tied to PIRQA on the ICH -- which is tied to intpin 16 on its IOAPIC. Typically the USB controllers are mapped to this IRQ as well. Where this becomes a problem is our strategy of masking interrupts in the IOAPIC for devices whose ithread is active. If the same device interrupts again, its interrupt is diverted over the boot interrupt signal (because its masked) and shows up as an interrupt on IRQ16. The docs _imply_ that this is supposed to be disabled when APIC mode is enabled, but I don't think thats the case for most chipsets. The Intel P64H2 and PXH PCI-PCI bridge docs I've read don't have a disable register, although newer IO hubs (like the 6300ESB) do to quell it on their interrupt sources. A quick hack would be to blacklist intpin 16 on the first IOAPIC and bump any PCI devices that ACPI says are claiming that interrupt. I don't know how difficult this is to do with ACPI. How to handle this for ATPIC mode is a little difficult since the boot interrupt either gets routed to IRQ9 or ends up as a stray on IRQ7 (on my SCB2 at least -- other boards may vary). If anyone else has thought this through and can prove me wrong, please do so ... its late and my brain hurts from reading Intel docs :-) -- Doug White | FreeBSD: The Power to Serve dwhite_at_gumbysoft.com | www.FreeBSD.orgReceived on Thu Apr 07 2005 - 04:52:13 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:31 UTC