On May 14, 2005, at 1:54 AM, M. Warner Losh wrote:

In message: <[EMAIL PROTECTED]>
            Kirk Strauser <[EMAIL PROTECTED]> writes:
: On Friday 13 May 2005 04:06 pm, M. Warner Losh wrote:
:
: > Kirk's dmesg showed some interesting IRQ routing issues that might be
: > the problem:
: >
: > pir0: <PCI Interrupt Routing Table: 4 Entries> on motherboard
: > $PIR: BIOS IRQ 11 for 0.7.INTA is not valid for link 0x22
: > $PIR: BIOS IRQ 11 for 0.7.INTB is not valid for link 0x22
: >
: > Can you send me the output of http://people.freebsd.org/~msmith/pir.c
: > to make sure that's not the problem.
:
: Here it is:
:
: $PIR table at 0x2816d890 version 1.0
: PCI interrupt router at 0:0.0 vendor 0x0 device 0x0
: PCI-only interrupts [                       11            ]
: entry bus slot device
: 00: 00 00 08 INTA 00 [ ] : INTB 00 [ ] : INTC 00 [ ] : INTD 00 [ ] : 01: 00 00 04 INTA 02 [ 9 ] : INTB 00 [ ] : INTC 00 [ ] : INTD 00 [ ] : 02: 00 00 06 INTA 00 [ ] : INTB 00 [ ] : INTC 00 [ ] : INTD 00 [ ] : 03: 00 00 07 INTA 22 [ 10 ] : INTB 22 [ 10 ] : INTC 22 [ 10 ] : INTD 22 [ 10 ]
:
:
: > What does vmstat show for irq 10?  How about other IRQs?
:
: It doesn't show irq 10 at all:
:
: interrupt                          total       rate
: irq0: clk                          74997         99
: irq1: atkbd0                         975          1
: irq6: fdc0                           209          0
: irq7: ppc0                             1          0
: irq8: rtc                          96004        127
: irq13: npx0                            1          0
: irq14: ata0                         2777          3
: irq15: ata1                           50          0

OK.  It looks like the PCI routing code in this case is in error.  It
assumes that PCI only interrupts are the only ones that can be in the
PIR table (not sure why it doesn't complain about irq9 in INTA for
your device at pci0.4, but that's likely because there's no device in
dmesg there).

That's not what it means. The 'BIOS IRQ' bit means that it read IRQ 11 out of the intlin register because the BIOS put it there, but the BIOS value seems invalid. I have a patch to make the PIR code trust the BIOS in this case over the $PIR table that you can test if you want. Actually, I committed the patch finally a while ago. It is rev 1.117 in HEAD. It should backport to 5.x directly. Try that and see if it fixes your problem.

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

_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to