Weird PCI interrupt delivery problem

[Craig Boston]

On Wed, Nov 30, 2005 at 10:35:13AM -0500, John Baldwin wrote:
> > With both ACPI & APIC enabled, it only lasts a few seconds.
> 
> You didn't have to futz with the routing in this case?

No, I just took the default routing specified by ACPI.

> > With ACPI disabled, the system panics because the mptable is broken.
> > However, I was able to hack the kernel to override the mptable and
> > route the interrupts to the correct pins.
> 
> You know that you can override individual routings just using tunables
> without having to hack the table.  Just use something like:

Oh yeah, thanks, I forgot about that.  Though I think I would have to
hack the table anyway just to get the system booted -- it panics due to
the bogus entries long before it tries to route any INTs.

> hw.pci0.2.INTA.irq=17  to route pci bus 0, slot 2, pin A# to IRQ 17
> (apic 0, intpin 17).  Determining the correct intpins can be tricky
> though.

I studied the _PRT entries in the DSDT and compared with what Windows
was using to figure out where they should go, I'm 99% sure it's correct.

> The code does not assume APIC at all.  What does an unmolested kernel
> actually do with ACPI enabled but APIC disabled?

Whoops, you're right.  The first time I tried that I must have made a
typo in the hint to disable the APIC because it "ignored" me and used it
anyway.  Then I read sys/i386/acpica/madt.c to mean that if an MADT
table is present it flips on APIC mode unconditionally.

A GENERIC kernel with ACPI but no APIC does the same thing, however.
Everything ends up on IRQ 11 and it does just that much quicker.
vmstat -i shows IRQ 11 frozen at 55 interrupts (the number varies per boot).

> > The final thing I tried is both APIC & ACPI disabled
> 
> Do you have a dmesg from this?  Preferably a verbose one to see if
> your $PIR has routing info for cbb0.

Yes, I have verbose dmesgs up at
http://www.gank.org/freebsd/l25/

(I've been running RELENG_6, but reverted to a 6.0 GENERIC to create
these as to rule out any local patches)

8259.txt is the one with both APIC & ACPI disabled.  I don't see a $PIR
table anywhere though -- I don't think this board was intended to be
run without ACPI...

> We mask the IRQs in the PIC while their ithread runs.  If your routing
> is all screwed up that might result in the problems you are seeing.
> Can you boot into Windows and jot down the IRQs it uses for each
> device

I'm pretty sure the routing is OK, but am game to try anything that
might help.  I don't have Windows on this machine anymore, so I called a
friend with an identical laptop and had him go through device manager.
Highlights include USB on IRQ 19, the integrated RealTek NIC on IRQ 21,
and the MiniPCI wireless on IRQ 22.  It matched exactly with with the
IRQ lines that BSD uses with APIC, with or without ACPI.

> and then (if you are up to it), provide verbose dmesg's of an
> unpatched kernel for the 4 cases of + ACPI + APIC, - ACPI + APIC, +
> ACPI - APIC, - ACPI - APIC?

Sure, see the link above.  The files are:
8259.txt	- ACPI - APIC
acpi+apic.txt	+ ACPI + APIC
acpi.txt	+ ACPI - APIC

I couldn't get one for - ACPI + APIC as it panics on bootup and this
machine doesn't have a serial port.  I did post a verbose boot with my
patched kernel for that under apic+patches.txt.

Also in there is mptable.txt, which shows the broken mptable.
mptable-fixed.txt is the output of the mptable command when running with
a patched kernel in APIC (no ACPI) mode.

Craig