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?
Kind Regards,
Donald
________________________________
> Date: Fri, 18 Apr 2008 18:17:23 +0200
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: ASUS WL-138G v2 working with different sprom values
> CC: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [email protected]
>
> According to the README of the Vista driver, the card supports Afterburner,
> but not SpeedBooster. SpeedBooster is only supported by WL-138gE. However,
> the page on asus.com about the card no longer talks about Afterburner support
> (it did, previously). So, the right overrides are 0x0048 for
> 14E4:4318:1043:100F, and 0x0248 for the WL-138gE version (14E4:4318:1043:120F
> if I remember correctly). (This message is a repost because I forgot to CC
> the list, as usual.)
>
> On Fri, Apr 18, 2008 at 6:00 PM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> On Friday 18 April 2008 17:51:29 Stefanik Gábor wrote:
>> Bisection complete!
>> After testing numerous settings for BoardFlags, I found that the only ones
>> to have a benefical effect on the card is 0x4049/0x4249 and 0x0048/0x0248,
>> which differs from the original 0x0049 only in the BFL_BTCMOD bit, which is
>> 0 by default, but 1 in this configuration. Not only that, setting BoardFlags
>> to 0x4049 and leaving everything else as is in the original Asus SPROM fixes
>> BOTH the "No TX" and the "ping time cycle" bugs! Even
>> monitoring/packetspamming while operating works perfectly. The setting
>> 0x4249 produces the same (perfectly-working) result, only with Afterburner
>> marked as supported. (Not sure if it actually gets enabled, though.) Setting
>
> The afterburner bit is not used in the driver.
>
>> BFL_FEM to 1 (0x4849 or 0x4A49) introduces the "ping cycle" bug, most likely
>> because the card doesn't actually support the Front-End Module. BFL_HGPA=1
>> (0x6049/0x6249) causes ping packet loss /duplicate count to increase
>> somewhat, likely because the card doesn't have a high-gain PA. 0x0048 and
>> 0x0248 also work fine, although this setting disables Bluetooth coexistence
>> (BFL_BTCOEXIST).
>
> As the card doesn't have a BT chip, this is the correct thing to do.
>
>> So, it looks like BoardFlags was intended to be 0x4249, but
>
> I'm not too sure on the afterburner bit. The packaging box of my card
> does not tell anything about supported rates beyond 54MBit. So it most
> likely does not support afterburner.
>
>> Asus incorrectly sets it to 0x0049, which completely breaks transmission in
>> b43.
>>
>
>> "0x0001: BFL_BTCOEXIST: Board implements Bluetooth coexistance[sic]". I
>> don't know if "coexistance" is a misspelling or if it's the correct spelling
>> in British, but if it's unintended, then it should be fixed. (Just
>> nit-picking, sorry.)
>
> That bit is most likey what is actually the wrong one.
>
> --
> Greetings Michael.
>
>
>
> --
> Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
_________________________________________________________________
Search for local singles online @ Lavalife - Click here
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Flavalife9%2Eninemsn%2Ecom%2Eau%2Fclickthru%2Fclickthru%2Eact%3Fid%3Dninemsn%26context%3Dan99%26locale%3Den%5FAU%26a%3D30290&_t=764581033&_r=email_taglines_Search_OCT07&_m=EXT
_______________________________________________
Bcm43xx-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
