Re: Potential source of interrupt aliasing

On Thursday 07 April 2005 02:52 am, Doug White wrote:
> 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).

You can't just move APIC interrupts around.  They are physically wired that 
way.  ATPIC mode won't matter.  If there is a way to disable this in 
hardware, then it needs to be done in the _PIC method of the BIOS for ACPI.  
I don't think there's any way to allow for this for non-ACPI though as the 
MPTable spec only mentions the IMCR which these boards don't implement.

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org