Bug 240343

Created attachment 154843 [details]
lspci -vvv

Created attachment 154845 [details]
dmesg for kernel-2.6.21-1.3142.fc7 (the last working kernel)

Created attachment 154846 [details]
dmesg for kernel-2.6.21-1.3149.fc7 (not working)

PCI IDs were removed intentionally to avoid conflicts between the old and new 
(i.e. mac80211) bcm43xx drivers.  Unfortunately, the bcm4318 is a problem 
child -- FWIW, the new driver works find on my 4318 devices.

You might try this (as root):

   echo "14e4 4318" > /sys/bus/pci/drivers/bcm43xx/new_id

Does that cause the bcm43xx driver to take ownership of the device and 
register eth1?

Either way, please also post at least dmesg output from using the 
bcm43xx-mac80211 driver instead of bcm43xx.  It may help.

Created attachment 154862 [details]
dmesg for kernel-2.6.21-1.3149.fc7 with bcm43xx-mac80211

Hi John,

Thanks, the "echo" command makes bcm43xx use the device (now I'm writing this
on 3149 kernel and bcm43xx driver, using that command).

I understand that bcm43xx-mac80211 is the new driver and you are pushing it,
sadly it doesn't works for me :-/

Anyways, I'm willing to help to make this driver work on my laptop.

So I tried bcm43xx-mac80211 again: I removed the blacklist entry, and rebooted.

after booting I have bcm43xx-mac80211 loaded, eth1 is configured, but pinging
my AP doesn't works (I get tons of 'From 192.168.1.62 icmp_seq=36 Destination
Host Unreachable'). 'iwlist scan' shows my AP, and from dmesg (you will see it
attached) it seems associated.
When icmp_seq becomes greater than 200, I stopped ping, did a 'ifdown eth1;
rmmod `lsmod | fgrep bcm | cut -c-20`', and then 'modprobe bcm43xx-mac80211',
waited a couple of seconds, and did a 'ifup eth1', restarted ping, and for a
while I got 'Destination Host Unreachable', but after a while ping started to
work.
So I tried opening firefox, and typing 'www.google.com': it took more than 4
minutes to load the full page, and never finished loading the image with the
colored 'google' logo.

Note that I work as a C programmer, and even if I almost never did kernel
hacking, I'm able to rebuild a kernel from sources and stick some debug code or
do some simple tweaking, if you tell me what to do.

Thanks!

Please try the latest kernel available from here:

   http://people.redhat.com/davej/kernels/Fedora/

There are some important bcm43xx-mac80211 updates in there.  Do those kernels 
work any better for you?

I have tried kernel 2.6.21-1.3194.fc7 from davej's repository, and sadly it
doesn't make bcm43xx-mac80211 any better. Everything behaves as with previous
kernels (I have tried almost any kernel in the 'development' repository).

BTW I have also tried changing firmware version: before I had version 4.40
extracted from the HP drivers for my laptop. So I tried also downloading
http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2, but also
this attempt was unsuccessful.

A can post the dmesg with the latest kernel if you want to take a look, but from
a quick look it doesn't seems different from the 3149.

You might try the "bcm43xx-old-config" script attached to the message here:

   http://marc.info/?l=fedora-list&m=118096307315653&w=2

Does that (i.e. using bcm43xx instead of bcm43xx-mac80211) resolve the issue 
for you?

Yes, it works, I;m using something like that since you suggested it on comment  #4.

In short, this is what happens on my laptop:
- bcm43xx-mac80211 never worked.
- bcm43xx works from almost when it was first included in mainline (well, the
first versions barely worked, but from 2.6.19 works well, with some problems
when the signal strength was low, but lately the driver improved a lot on this area)
- right know I have 'blacklist bcm43xx-43xx' in /etc/modprobe.d/blacklist and
'modprobe bcm43xx fwpostfix=.3
echo "14e4 4318" > /sys/bus/pci/drivers/bcm43xx/new_id' on /etc/rc.local, to
make it work.

Let me know if I can try something else to make bcm43xx-mac80211 work (now I'm
running 2.6.21-1.3224.fc7 from davej repository after a clean F7 install from
DVD, and still doesn't work).

Well, doing some random tests I found something that you may find interesting: I
tried switching my access point (a Linksys WAG200G) to "B-only" mode. this way
the bcm43xx-mac80211 driver seem to work well. So I suppose the problems are in
G-mode.
BTW, if I leave the computer on trying to ping the router (configured as
AutoSelect-mode) with bcm43xx-mac80211, after an hour or so, I can connect to
internet via wireless, but the connection is unstable: for example, trying to
download a FC7 iso image with wget, the download rate changes wildly, and
sometimes drops to zero, and the only way to restore the download is to stop
wget and rerun it.

As I use the wireless connection mostly for internet, I can even leave the
router configured as B-only: sadly my other wireless card (a Linksys WUSB54G
version 4, using the rt2500usb driver) doesn't work at all with the router in
B-mode (and even inG-mode making it work requires a lot of work, but this is
another issue :-))

I couldn't find a way to tell bcm43xx-mac80211 to work as 'B-only', every time I
try something like:

iwconfig eth1 rate 11Mb/s

I get:
Error for wireless request "Set Bit Rate" (8B20) :
    SET failed on device eth1 ; Operation not supported.

Now I see that if I do an 'iwconfig eth1' with bcm43xx I get:

eth1      IEEE 802.11b/g  ESSID:"CASA"  Nickname:"sixtyfour.casa.net"
          Mode:Managed  Frequency=2.422 GHz  Access Point: xx:xx:xx:xx:xx:xx   
          Bit Rate=24 Mb/s   Tx-Power=18 dBm   
          RTS thr:off   Fragment thr:off
          Encryption key:xxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xx   Security mode:open
          Link Quality=51/100  Signal level=-66 dBm  Noise level=-72 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

while using bcm43xx-mac80211:

eth1      IEEE 802.11g  ESSID:"CASA"  
          Mode:Managed  Frequency:2.422 GHz  Access Point: xx:xx:xx:xx:xx:xx   
          Bit Rate=11 Mb/s   
          Retry min limit:7   RTS thr:off   Fragment thr=2346 B   
          Encryption key:xxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xx
          Link Quality=32/100  Signal level=-62 dBm  Noise level=-72 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

maybe is only a cosmetic difference, but for bcm43xx it says 'IEEE 802.11b/g',
but for bcm43xx-mac80211 i get 'IEEE 802.11g'.

There have been a lot of updates to the bcm43xx-mac80211 driver in recent 
rawhide kernels.  Is this still a problem with those kernels?

Well, sadly, with new kernels (I have tried 2.6.23-0.61.rc1.git9.fc8 on F7 and
on F8T1) it's even worse: I can't get it to work. As I said, setting my access
point to 'B-only' mode, bcm43xx-mac80211 used to work with older kernels. As
usual, the driver bcm43xx works.
As always, 'iwlist scan' works, I can configure the interface with 'iwconfig'
and bring it up with 'ifconfig', but trying to ping my AP fails.

But I have also found that even kernel 2.6.22.1-41.fc7 doesn't work anymore. The
last working kernel is 2.6.22.1-36.fc7 (I got it from davej repository).
Doing a diff between .36 and .41 kernels show a lot of changes in bcm43xx-mac80211.

I can try to bisect it from wireless git it you feel it could be useful.

Well, I have finally some good news to report: after upgrading today my rawhide
installation, the new kernel (2.6.23-0.105.rc3.fc8, yes, on this kernel
bcm43xx-mac80211 got renamed to b43) seems to work. I have tried with my AP
configured for 80211b only and for mixed mode, and I had no problems.

This is the first time I can post a comment to bugzilla using the new driver!

I tried running the previous kernel ( 2.6.23-0.104.rc3.fc8), and after a lot of
reboots, I can confirm that every time I tried the old (.104) kernel
bcm43xx-mac80211 is broken, while every time I used the new kernel (.105) b43 works.

I hope the difference is not only a simple rename... :-)

Anyways, I will keep testing newer kernels, and come back if something goes bad.