wi0 is always status: no carrier
M. Warner Losh
imp at bsdimp.com
Fri May 13 22:54:30 PDT 2005
In message: <200505131901.03493.kirk at strauser.com>
Kirk Strauser <kirk at strauser.com> 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).
In src/sys/i386/pci/pci_pir.c, try changing:
static int
pci_pir_valid_irq(struct pci_link *pci_link, int irq)
{
if (!PCI_INTERRUPT_VALID(irq))
return (0);
return (pci_link->pl_irqmask & (1 << irq));
}
to be
static int
pci_pir_valid_irq(struct pci_link *pci_link, int irq)
{
if (!PCI_INTERRUPT_VALID(irq))
return (0);
return (1);
}
and let me know if it works for you. The older code, before some
recent changes, didn't have this sanity check in it because many older
systems were, ummm, suboptimal in how they presented the $PIR to the
system. Looks like you might have one of these systems. I think I
still have a laptop that had this defect in my laptop pile, but
finding it may be hard...
Warner
More information about the freebsd-stable
mailing list