Weird PCI interrupt delivery problem

[Craig Boston]

On Fri, Dec 02, 2005 at 08:17:53AM -0500, John Baldwin wrote:
> If an MADT exists we do use the APIC and don't use ATPICs.  That's
> normal.
> 
> > 2. I "solved" the previous problem by modifying the ASL to assume
> > PIC mode, and then the tunables started working.  It was only able
> > to move devices on the "near" side of the bridge (i.e. on pci0), but
> > they did work briefly on IRQ 10 before freezing just as before.
> 
> You shouldn't have to do that.  The ACPI standard clearly states that
> machines boot up in PIC mode by default and you only need to call _PIC
> to switch to either APIC or SAPIC (ia64) mode.

Yeah, that was my bad.  I misread apic_register_enumerator as
acpi_register_enumerator.  After tracing it down I see that the MADT
check is called after the check for hint.apic.0.disabled.

> Did you disable APIC before trying the tunables BTW?

Yes, however the first time I only tried tunables for LNKA, B, and C
(was typing them by hand).  Later I tried with loader.conf and set all
8.  Another odd thing is that the dmesg lines for the LNK objects still
report irq 11, though the devices themselves do attach to 10.

> Interesting.  How about IRQ 11 in non-APIC mode, is it programmed to 
> level/low?

If it's not mentioned in verbose dmesg, how do I tell what it's
programmed to?  Is there already some way to do it that's easier than
writing something to read the PIC registers?

> hw.pci9.1.INTA.irq=11
> Also, try this hint with ACPI without APIC.  It looks like your BIOS doesn't 
> include entries for the PCI9 bus in the PIC version of the _PRT (see no PRT 
> messages in ACPI dmesg) so cbb0 doesn't get an IRQ there either.

The hint "works" with ACPI, in that cbb0 attaches.  However by the time
I'm able to insert a card, irq 11 has already died so nothing happens.

Craig