2009/8/14 Mark Huijgen <[email protected]>: > Gábor Stefanik wrote: >>> >>> ifconfig wlan0 >>> wlan0 Link encap:Ethernet HWaddr FF:FF:FF:FF:FF:FF >>> BROADCAST MULTICAST MTU:1500 Metric:1 >>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0 >>> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 >>> collisions:0 txqueuelen:1000 >>> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) >>> >>> ifconfig wlan0 up >>> SIOCSIFFLAGS: Cannot assign requested address >>> >> >> Uhh, that doesn't look good... >> > I've investigated with some SSB debugging: > [ 4895.592113] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x16, vendor > 0x4243) > [ 4895.592125] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0F, > vendor 0x4243) > [ 4895.592135] ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x0A, vendor 0x4243) > [ 4895.592145] ssb: Core 3 found: PCI-E (cc 0x820, rev 0x09, vendor 0x4243) > [ 4895.612051] ssb: Found rev 1 PMU (capabilities 0x02A62F01) > [ 4895.620727] ssb: SPROM revision 8 detected. > [ 4895.620732] ssb: MAC ff:ff:ff:ff:ff:ff > [ 4895.642495] ssb: Sonics Silicon Backplane found on PCI device > 0000:10:00.0 > > I added the ssb: MAC line, sprom extraction seems incorrect for this > device (is ssb up to date enough in wireless-testing for this device?).
Hmm... could you run "sudo cat $(find /sys -name ssb_sprom) > ~/ssb_sprom_copy", then upload ~/ssb_sprom_copy to somewhere? SSB in wireless-testing is up-to-date to the best of my knowledge - it definitely handles MAC address extraction. > >> >>> Did some looking around and it seems b43_op_start() is never called, so >>> its bailing out somewhere in mac80211? Something to do with the mac addr >>> being alls FF's? >>> >> >> Yes, FF:FF:FF:FF:FF:FF is not a valid MAC. Mac80211 refuses to >> initialize a card with an invalid MAC address. >> Now, the question is, how does the MAC address end up being >> FF:FF:FF:FF:FF:FF...? Presumably there is a switch(phy->type) in the >> generic (non-LP-specific) code that doesn't have case B43_PHYTYPE_LP >> and returns FF:FF:FF:FF:FF:FF as the default. I'll investigate. >> >> BTW could you post the output of "iwconfig wlan0", "iw dev wlan0 info" >> and "iw phy phy3 info" (replace phy3 with the phy name from dmesg)? > > # iwconfig wlan0 > wlan0 IEEE 802.11bg Mode:Managed Access Point: Not-Associated > Tx-Power=0 dBm > Retry long limit:7 RTS thr:off Fragment thr:off > Encryption key:off > Power Management:off > > # iw dev wlan0 info > Interface wlan0 > ifindex 16 > type managed > > # iw phy phy13 info > Wiphy phy13 > Band 1: > Frequencies: > * 2412 MHz [1] (27.0 dBm) > * 2417 MHz [2] (27.0 dBm) > * 2422 MHz [3] (27.0 dBm) > * 2427 MHz [4] (27.0 dBm) > * 2432 MHz [5] (27.0 dBm) > * 2437 MHz [6] (27.0 dBm) > * 2442 MHz [7] (27.0 dBm) > * 2447 MHz [8] (27.0 dBm) > * 2452 MHz [9] (27.0 dBm) > * 2457 MHz [10] (27.0 dBm) > * 2462 MHz [11] (27.0 dBm) > * 2467 MHz [12] (disabled) > * 2472 MHz [13] (disabled) > * 2484 MHz [14] (disabled) > Bitrates (non-HT): > * 1.0 Mbps > * 2.0 Mbps (short preamble supported) > * 5.5 Mbps (short preamble supported) > * 11.0 Mbps (short preamble supported) > * 6.0 Mbps > * 9.0 Mbps > * 12.0 Mbps > * 18.0 Mbps > * 24.0 Mbps > * 36.0 Mbps > * 48.0 Mbps > * 54.0 Mbps > max # scan SSIDs: 4 > Supported interface modes: > * IBSS > * managed > * AP > * AP/VLAN > * WDS > * monitor That's also wrong - the driver should be registering an 5GHz band as well (as I haven't yet added a check as to whether the LP-PHY in question is A/G or G-only - so getting only one band means something is limiting registration to G mode). BTW there is another problem that will prevent starting the device once this is fixed (firmware loading fails) - I'm about to submit a patch for that one soon. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
