FreeBSD 7 doesn't see AR5212 (Netgear WPN511) via PCI/Cardbus Adapter

[Warner Losh]

From: Sam Leffler <sam at errno.com>
Subject: Re: FreeBSD 7 doesn't see AR5212 (Netgear WPN511) via PCI/Cardbus Adapter
Date: Wed, 20 Feb 2008 08:38:32 -0800

> Michael C. Cambria wrote:
> > Benjamin Close wrote:
> >>
> >> Perhaps the relevant sections of a boot -v and pciconf -lv could help.
> >
> > When I made this discovery, I didn't have access to the system with 
> > the pic->cardbus, just the laptop.
> > I have tried with another ath based card which arrived last night, 
> > with the same result.  Here is pciconf -lv and boot -v with the 
> > Netgear WPN511 plugged in at boot time.  The pci->cardbus adapter is 
> > detected.  Using various 802.11b cards, it works just fine.
> >
> > cbb0 at pci0:1:8:0:    class=0x060700 card=0x3000133f chip=0xac50104c 
> > rev=0x01 hdr=0x02
> >    vendor     = 'Texas Instruments (TI)'
> >    device     = 'PCI1410 PC card cardBus Controller'
> >    class      = bridge
> >    subclass   = PCI-CardBus
> >
> > wlan_amrr: <AMRR Transmit Rate Control Algorithm>
> > wlan: <802.11 Link Layer>
> > ath_rate: version 1.2 <SampleRate bit-rate selection algorithm>
> > null: <null device, zero device>
> > nfslock: pseudo-device
> > random: <entropy source, Software, Yarrow>
> > io: <I/O>
> > kbd: new array size 4
> > kbd1 at kbdmux0
> > mem: <memory>
> > Pentium Pro MTRR support enabled
> > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, 
> > RF5413)
> >
> > [deleted]
> >
> > cbb0: <TI1410 PCI-CardBus Bridge> at device 8.0 on pci1
> > pcib1: cbb0 requested memory range 0xfe900000-0xfeafffff: good
> > cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xfe900000
> > cardbus0: <CardBus bus> on cbb0
> > pccard0: <16-bit PCCard bus> on cbb0
> > pcib1: matched entry for 1.8.INTA
> > pcib1: slot 8 INTA hardwired to IRQ 17
> > ioapic0: routing intpin 17 (PCI IRQ 17) to vector 53
> > cbb0: [MPSAFE]
> > cbb0: [ITHREAD]
> > cbb0: PCI Configuration space:
> >  0x00: 0xac50104c 0x02100107 0x06070001 0x00024010
> >  0x10: 0xfe900000 0x020000a0 0x20030201 0xfffff000
> >  0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc
> >  0x30: 0x00000000 0xfffffffc 0x00000000 0x07400111
> >  0x40: 0x3000133f 0x00000001 0x00000000 0x00000000
> >  0x50: 0x00000000 0x00000000 0x00000000 0x00000000
> >  0x60: 0x00000000 0x00000000 0x00000000 0x00000000
> >  0x70: 0x00000000 0x00000000 0x00000000 0x00000000
> >  0x80: 0x0844b060 0x00000000 0x00000000 0x00001d92
> >  0x90: 0x600200c0 0x00000000 0x00000000 0x00000000
> >  0xa0: 0xfe110001 0x00c00000 0x0000000b 0x0000001f
> >  0xb0: 0x08000000 0x00000000 0x00000000 0x00000000
> >  0xc0: 0x00000000 0x00000000 0x00000000 0x00000000
> >  0xd0: 0x00000000 0x00000000 0x00000000 0x00000000
> >  0xe0: 0x00000000 0x00000000 0x00000000 0x00000000
> >  0xf0: 0x00000000 0x00000000 0x00000000 0x00000000
> > em0: <Intel(R) PRO/1000 Network Connection Version - 6.7.3> port 
> > 0xdec0-0xdeff mem 0xfe9e0000-0xfe9fffff irq 18 at device 12.0 on pci1
> > em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfe9e0000
> >
> This sounds like an issue I hit recently.  It appears the cardbus code 
> broke sometime between 6.x and 7.0 causing the card to not be powered 
> up.  It looks to be specific to this bridge/cardbus chip.  Warner is 
> aware of the issue but I'm not sure if he's found time to look at it (or 
> if he can reproduce it).

I can't reproduce it on my machine(s) here.  Next time I'm colocated
with someone who can reproduce it, I'll look into it.  So far there's
been no common thread between the different people seeing the problem
(well, in these two data points now).

There are two different bugs that I'm aware of.  One is pci bus
numbering (which means that *NO* cardbus cards will work, but all
16-bit "r2" cards will work).  The other is the power issue that Sam
is talking about.  But the first issue should be identical in both 6.x
and 7.0.

I hope to have a fix for this before 7.1 ships.

Warner