kala mazoo wrote: > Greets, > > Apologies for previous noise about 2.6.24 ooopsing. It wasn't > relevant.. > > As queried, I grabbed the (then) latest wireless-testing tree, and that > compiled & > loaded modules without the noted errors. The asus card worked, although in > this > case the rx/tx LED remains off the entire time. The performance was a bit hap- > hazard, and dmesg would contain passages like ; > > May 5 19:31:39 sfs64 kernel: b43-phy0 ERROR: MAC suspend failed > May 5 20:58:44 sfs64 kernel: b43-phy0 ERROR: MAC suspend failed > May 5 21:18:57 sfs64 kernel: wlan0: No ProbeResp from current AP > 00:18:4d:2c:57:5e - assume out of range > > ...and most of the time I found I had to manually reassociate with the AP > using > iwconfig to re-establish the link. Typically what I'll try to do to test the > link, is > use mythtv to stream hdtv content across it -- this simply would not happen, > and if it could be got running the dropped packet count made viewing the > stream most annoying. No file transfers ever seemed corrupted, just real time > streaming was so affected. > > As of today May 06 and an update of the wireless-testing tree, the new > kernel build seems to be working much better, and dmesg chatter has stopped > altogether as per above. Nor does the link association drop-out any more as > per above. Thruput is much improved, and..eg; mythtv streaming now almost > works perfectly - there's still a replay 'stutter' I have to get to the > bottom of > that coincides with sporadic packet drop, however things are -much- better > than previously experienced here. For the record...; > > ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243) > ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09, vendor 0x4243) > ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243) > ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243) > ssb: SPROM revision 2 detected. > ssb: Sonics Silicon Backplane found on PCI device 0000:01:07.0 > > b43-phy0: Broadcom 4318 WLAN found > b43-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7 > b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 8 > phy0: Selected rate control algorithm 'pid' > Broadcom 43xx driver loaded [ Features: P, Firmware-ID: FW13 ] > > b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10) > b43-phy0 debug: Chip initialized > b43-phy0 debug: 32-bit DMA initialized > b43-phy0 debug: Wireless interface started > b43-phy0 debug: Adding Interface type 2 > b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac: > ff:ff:ff:ff:ff:ff > wlan0: Initial auth_alg=0 > wlan0: authenticate with AP 00:18:4d:2c:57:5e > ADDRCONF(NETDEV_UP): wlan0: link is not ready > wlan0: RX authentication from 00:18:4d:2c:57:5e (alg=0 transaction=2 status=0) > wlan0: authenticated > wlan0: associate with AP 00:18:4d:2c:57:5e > wlan0: RX AssocResp from 00:18:4d:2c:57:5e (capab=0x411 status=0 aid=1) > wlan0: associated > ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready > wlan0: switched to short barker preamble (BSSID=00:18:4d:2c:57:5e) > wlan0: no IPv6 routers present > > This is just using WEP and with kernel 2.6.25wl IOMMU=on. This level of > debug has been otherwise quiet since init...20hours ago. (previously I'd > become used to the above error occurring every 2-3hours or so). I should > add I haven't seen this happening on the 32bit box at all (I haven't yet > upgraded it's tree to current 'cos it hasn't demonstrated the same problem). > > > I'm a tad confused about the rx/tx LED behaviour - although I do understand > what was previously said regarding this. My confusion stems from the fact > that b43 & 2.6.24 on 32bit with the asus 138gv2 card flashed with the sprom > image Stefanik provided, got the card working initially - it also got the > rx/tx > LED working 'as it should'. Now...stupid me thought this would merely be a > case of looking at the sprom values between the two different sprom images, > to deduce what the values should be...however, if we're talking about these > bits here -; > > SPROM(0x64, LED 0 behaviour) = 0xFF > SPROM(0x65, LED 1 behaviour) = 0xFF > SPROM(0x66, LED 2 behaviour) = 0xFF > SPROM(0x67, LED 3 behaviour) = 0xFF > > ....then they're actually the -same- in both sprom image varients. > > Apparently there's more than just these bits in the sprom controlling the LED > behaviour? Does anyone know what that might be?
I'm not sure what you should expect from the 0xFF values; however, you have not enabled the LED select stuff in your kernel. If you had, you would see lines like b43-phy0 debug: 64-bit DMA initialized Registered led device: b43-phy0::tx Registered led device: b43-phy0::rx Registered led device: b43-phy0::radio Larry _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
