On Friday 18 April 2008 16:44:58 Stefanik Gábor wrote: > That's *exactly* what I am doing at this moment. Here are my findings so > far: > > WL-138G V2 comes with BoardFlags=0x0049. That would mean, no Afterburner > (among other things), even though Asus specifically advertises this card as > supporting Afterburner. When I set it > to0x6A49, the card suddenly comes to life to some extent, as I can > associate/DHCP and Radiotap injection works, but loading webpages is > eXXXXtremely slow, and pinging my AP results in an anomalous output, > where the return time of the pings cycles between > 3ms, 350ms and 600ms, with some packets dropped, and others received > twice (duplicates). When I flash the > entire SPROM that I sent to Larry and Kala Mazoo minus the MAC address > and the subsystem IDs, the card works much > better, web pages download fast, ping times don't cycle, but pinging my AP > still shows a lot of duplicates (although no packets get lost). This > suggests that the weird "ping cycling" bug and the extremely low > throughput is > due to a mismatch between BoardFlags and the paXbY values, and not a > driver bug. I will do some more bisecting on the individual BoardFlags > values to see which one triggers the bug.
It is the BFL_BTCMOD this bit selects which GPIO pin the microcode uses for disabling the bluetooth chip. I think the GPIO pin is actually connected to the power amplifier on this device. So you see what this results in. :) So the SPROM is buggy and we are missing some workaround for it in the driver. I think the correct workaround for this card would be to disable the BFL_BTCOEXIST bit, as there is no bluetooth chip on the card anyway. So I think that bit is the one that is wrong. (of course it's also wrong on lots of other cards without a bluetooth chip. But the bug doesn't trigger there, as they don't use that GPIO pin for something else) I'm not sure how to implement this workaround. How should we decide when to nuke the bit? Oh, and btw adding a return; early in b43_bluetooth_coext_enable() should temporarly workaround the issue. At least it does for me. -- Greetings Michael. _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
