Yes, it's a kernel from source, renamed to the current fc6 uname-r for a closed video driver. [EMAIL PROTECTED] linux]# cd /usr/src/linux && grep -i bcm .config | grep -i debug
CONFIG_BCM43XX_DEBUG=y
CONFIG_BCM43XX_MAC80211_DEBUG=y

Ehud

Pavel Roskin wrote:
On Mon, 2007-04-09 at 17:52 -0700, Ehud Gavron wrote:
Removed module.symvers. Make; make install. rmmod bcm43xx hung (yes I forgot to ifconfig down ;) reboot... module now works perfectly.

This means that you already have CONFIG_BCM43XX_DEBUG defined
in .config, right?  I guess you had to recompile the kernel anyway, or
at least reconfigure it.  That's not how a _standalone_ driver should
work, in my opinion.

I am unable to see the behavior I saw before: namely ifconfig rxcount goes to 0, txcount goes low, radio off, radio on, rxcount+, txcount+++, dhcp works, give it a second, down again. repeats.

Right now what I'm seeing is a perfectly working system. I have moved different APs within the same ESSID (WEP enabled) and no problems are evident. I'm getting TCP throughput of 7Mbps (on my Comcast 6Mbps link) and I haven't configured any in-LAN testing facilities (yet. The night is young.)

Yes, the current bcm43xx is pretty good at data transfer.  And it
doesn't crash my Mac anymore, even though I put my oldest card there,
just to make things harder.  And it works with a bizarre Linksys AP to
which bcm43xx_mac80211 won't connect.

Just be careful with rates of 48 and 54 Mbps, they are still unstable.
The default 24 Mbps is a good default for me.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Bcm43xx-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Reply via email to