broadcom-wl not working for 2.6.30 kernel update

Gödel · #1 22nd September 2009, 04:05 PM

In the latest Fedora 11 updates, kernel 2.6.30.5-43.fc11.x86_64 breaks broadcom-wl functionality on my BCM4312 wifi adapter

Code:

$ lspci -v | awk '/Ether|Net/,/^$/'
03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)
	Subsystem: Dell Device 01f1
	Flags: bus master, fast devsel, latency 64, IRQ 17
	Memory at f9bfe000 (32-bit, non-prefetchable) [size=8K]
	Capabilities: <access denied>
	Kernel driver in use: b44
	Kernel modules: b44

0c:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01)
	Subsystem: Dell Wireless 1395 WLAN Mini-Card
	Flags: bus master, fast devsel, latency 0, IRQ 17
	Memory at f9ffc000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: b43-pci-bridge
	Kernel modules: wl, ssb

Code:

$ iwconfig
lo        no wireless extensions.

pan0      no wireless extensions.

eth0      no wireless extensions.

Not sure what the issue is here, and why the b43-pci-bridge driver is in use, I tried removing it and reloading wl but no joy.

In the meantime you can just boot the older 2.6.29 kernel, and if you want to use the 2.6.30 kernel then install ndiswrapper (yum install ndiswrapper) and reboot, the kmod will be auto-built, then I had to do the following sequence of commands

Code:

su -
ndiswrapper -i <path to>/bcmwl5.inf
modprobe -r b43
modprobe -r b44
modprobe -r ssb
modprobe ndiswrapper

and all is well, the modprobe commands can go in /etc/rc.local.

BCM43xx *.inf driver for ndiswrapper (32 and 64 bit) here

I hope this gets fixed soon as the broadcom-wl driver has been working perfectly, if anyone has found an easier fix please post.

(kmod-wl-2.6.30.5-43.fc11.x86_64-5.10.91.9-4.fc11.2.x86_64 is installed)

lollysticky · #2 22nd September 2009, 04:57 PM

perhaps filing a bug report might be a good idea.

BlueC · #3 22nd September 2009, 11:29 PM

Hi, I'm the package maintainer for wl-kmod/broadcom-wl. This is odd, as I'm using it right now on the same kernel and architecture and it works just fine. it was broken for a little while but I fixed it about 2 weeks ago - just a couple of days after the new kernel was released.

To do any debugging here you'll need to remove all traces of ndiswrapper as it won't play nicely with wl-kmod. If you can do that, then do the following commands (to install and debug wl-kmod) and paste the output it would be useful to see to help me find what is happening:

Code:

yum install kmod-wl
rmmod ssb
rmmod ndiswrapper
modprobe wl
lsmod | grep wl

Thanks
Chris

BlueC · #4 22nd September 2009, 11:37 PM

Oh, just noticed this in your post

Code:

Kernel driver in use: b43-pci-bridge

That gives a major clue. Looks like bcm43xx or b43 is hogging the card; you should remove any RPMS related to either of these two as they conflict with the wl driver. Also check that you have the "broadcom-wl" package properly installed which should place a file in /etc/modprobe.d/broadcom-wl-blacklist.conf with these contents:

Code:

 
# modules blacklisted for broadcom-wl
blacklist bcm43xx
blacklist ssb
blacklist b43
blacklist ndiswrapper

Let me know how you get on with that.

Chris

Gödel · #5 23rd September 2009, 12:02 AM

Hi BlueC.

That hint about /etc/modprobe.d/broadcom-wl-blacklist.conf enabled me to get the wl driver working in the 2.6.30 kernel, but I had to add b44 to the blacklist:

Code:

$ cat /etc/modprobe.d/broadcom-wl-blacklist.conf 
# modules blacklisted for broadcom-wl
blacklist bcm43xx
blacklist ssb
blacklist b43
blacklist b44
blacklist ndiswrapper

Now after a reboot the wl driver is loaded fine.

Code:

03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)
	Subsystem: Dell Device 01f1
	Flags: bus master, fast devsel, latency 64, IRQ 10
	Memory at f9bfe000 (32-bit, non-prefetchable) [size=8K]
	Capabilities: <access denied>
	Kernel modules: b44

0c:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01)
	Subsystem: Dell Wireless 1395 WLAN Mini-Card
	Flags: bus master, fast devsel, latency 0, IRQ 17
	Memory at f9ffc000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: wl
	Kernel modules: wl, ssb

The only problem now is that the b44 driver for the Ethernet controller isn't loaded by default, but it can be loaded manually with modprobe so it's only a minor issue in my case.

Thanks.

Gödel · #6 23rd September 2009, 12:19 AM

one more point, I did try blacklisting b43-pci-bridge but it still got loaded and wl failed to load. My guess is that the b44 driver forces it to load, so wl needs to be loaded before b44, but I'm not sure how you would ensure that without blacklisting b44 and then manually loading afterwards.

BlueC · #7 23rd September 2009, 08:43 AM

Hi Gödel

Glad you got it working. Interesting problem that with the b44 driver - not sure whether I should add it to the default blacklist as it may disable people's ethernet. Please let me know if you find any solution to make it load the b44 after the wl driver, or some other way of stopping the conflict.

Thanks
Chris

Gödel · #8 23rd September 2009, 04:00 PM

Other people seem to have the same issue with b44 preventing wl loading, seems it causes ssb to load which then prevents wl loading:

http://www.linux-archive.org/kubuntu...r-manager.html
(see 4th post down by Paul L)

The bug was fixed in a Ubuntu package (jockey) back in march:
https://bugs.launchpad.net/ubuntu/+s...ey/+bug/333903

Quote:

This bug was fixed in the package jockey - 0.5-0ubuntu3

---------------
jockey (0.5-0ubuntu3) jaunty; urgency=low

* data/handlers/broadcom_wl.py: Fix spelling of the b43legacy module.
* data/handlers/broadcom_wl.py: Fix ordering of module loading if b44 is
needed/loaded as well: Blacklist b44, and load it in the "install wl"
rule, so that wl always comes first. (LP: #333903)
* Merge bug fixes from trunk:
- oslib.py: Do not grab lsb-release stderr.
- oslib.py: Append ".conf" suffix to blacklist file, since current
modutils deprecates anything else.
* data/handlers/{b43,broadcom_wl}.py: Rename blacklist-bcm43 to
blacklist-bcm43.conf, for the same reason.
* debian/jockey-common.postinst: Rename blacklist-{bcm43,local} to *.conf on
upgrades.

-- Martin Pitt <email address hidden> Sat, 07 Mar 2009 15:34:09 +0100

https://bugs.launchpad.net/ubuntu/+s...903/comments/9

http://aur.archlinux.org/packages.php?ID=19514
(see comment by gborzi 28th August)

http://www.ahmadnassri.com/post/1920...on-macmini-3-1

UPDATE: For WPA passphrase issues try manually installing the 5.10.91.9.3 driver

Gödel · #9 23rd September 2009, 04:14 PM

and poster "TIS" supplied a possible fix in the last comment on this page

http://www.cenolan.com/2008/11/rpm-i...driver-fedora/

Quote:

What I did: it occurrs (for now at least

) that everything works if the wl driver is loaded before ssb driver (I think it's because ssb driver wants to also manage my wireless card and uses some werid driver instead of wl). So I created a file in modprobe.d named ssb-and-wl
Contents:

install ssb /sbin/modprobe wl; /sbin/modprobe --ignore-install ssb;

In short, it ensures that IF the ssb driver is loaded, wl driver is also loaded and loaded before.
It might be not a beautiful solution, but... hey, it worked!

rgaelzer · #10 10th January 2011, 08:24 PM

Hi. I've just noticed the solution posted below.
I have exactly the same problem with my Dell Vostro 1500.
Is this still the only known workaround for this bug? Or is there any improvement that came around? I've been constantly updating the kernel/broadcom rpm's with F14 but I'm very lucky when I get a working wireless card using linux...
Thank you.

Quote:

Originally Posted by Gödel

and poster "TIS" supplied a possible fix in the last comment on this page

http://www.cenolan.com/2008/11/rpm-i...driver-fedora/

Gödel · #11 10th January 2011, 08:53 PM

Quote:

Originally Posted by rgaelzer

Hi. I've just noticed the solution posted below.
I have exactly the same problem with my Dell Vostro 1500.
Is this still the only known workaround for this bug? Or is there any improvement that came around? I've been constantly updating the kernel/broadcom rpm's with F14 but I'm very lucky when I get a working wireless card using linux...
Thank you.

Do you have a broadcom ethernet controller which uses the b44 adapter?

Code:

$ lspci -v | awk '/[nN]et/,/^$/'
03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)
	Subsystem: Dell Device 01f1
	Flags: bus master, fast devsel, latency 64, IRQ 10
	Memory at f9bfe000 (32-bit, non-prefetchable) [size=8K]
	Capabilities: <access denied>
	Kernel modules: b44

0c:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g LP-PHY (rev 01)
	Subsystem: Dell Wireless 1395 WLAN Mini-Card
	Flags: bus master, fast devsel, latency 0, IRQ 17
	Memory at f9ffc000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: wl
	Kernel modules: wl, ssb

In F14 I just blacklist b44 in /etc/modprobe.d/blacklist.conf and then manually load it with 'modprobe b44' on rare occasions that I need to use the ethernet connection.

rgaelzer · #12 11th January 2011, 11:53 AM

Quote:

Do you have a broadcom ethernet controller which uses the b44 adapter?
<snip>
In F14 I just blacklist b44 in /etc/modprobe.d/blacklist.conf and then manually load it with 'modprobe b44' on rare occasions that I need to use the ethernet connection.

Indeed I do:

Code:

03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)
	Subsystem: Dell Device 0228
	Flags: bus master, fast devsel, latency 64, IRQ 17
	Memory at fe5fe000 (32-bit, non-prefetchable) [size=8K]
	Capabilities: <access denied>
	Kernel driver in use: b44
	Kernel modules: b44

0c:00.0 Network controller: Broadcom Corporation BCM4321 802.11a/b/g/n (rev 03)
	Subsystem: Dell Wireless 1500 Draft 802.11n WLAN Mini-card
	Flags: bus master, fast devsel, latency 0, IRQ 17
	Memory at fe8fc000 (64-bit, non-prefetchable) [size=16K]
	Memory at f0000000 (64-bit, prefetchable) [size=1M]
	Capabilities: <access denied>
	Kernel driver in use: wl
	Kernel modules: wl, ssb

Your solution worked, as well as TiS's workaround of creating the "ssb-and-wl" file modprobe.d.
I think I'll stick to them for the time being.
Thank you.

rgaelzer · #13 19th August 2012, 07:56 PM

Quote:

Originally Posted by rgaelzer

Indeed I do:

Code:

03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)
	Subsystem: Dell Device 0228
	Flags: bus master, fast devsel, latency 64, IRQ 17
	Memory at fe5fe000 (32-bit, non-prefetchable) [size=8K]
	Capabilities: <access denied>
	Kernel driver in use: b44
	Kernel modules: b44

0c:00.0 Network controller: Broadcom Corporation BCM4321 802.11a/b/g/n (rev 03)
	Subsystem: Dell Wireless 1500 Draft 802.11n WLAN Mini-card
	Flags: bus master, fast devsel, latency 0, IRQ 17
	Memory at fe8fc000 (64-bit, non-prefetchable) [size=16K]
	Memory at f0000000 (64-bit, prefetchable) [size=1M]
	Capabilities: <access denied>
	Kernel driver in use: wl
	Kernel modules: wl, ssb

Your solution worked, as well as TiS's workaround of creating the "ssb-and-wl" file modprobe.d.
I think I'll stick to them for the time being.
Thank you.

Alas, it's not working anymore...
After I had to replace the hd, I installed F17 and then the above solution no longer works.
I posted yesterday a detailed account in this thread:
http://forums.fedoraforum.org/showthread.php?t=283336

The only way I can have both network cards working is by first blackmailing b44 and then manually modprobe it. This is not a desirable solution.

As a bit of further information, here's the output of 'ip add':

=============================================
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state DORMANT qlen 1000
link/ether 00:1c:26:51:d9:27 brd ff:ff:ff:ff:ff:ff
inet6 fe80::21c:26ff:fe51:d927/64 scope link
valid_lft forever preferred_lft forever
4: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:19:b9:86:06:90 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.14/24 brd 10.1.1.255 scope global em1
inet6 fe80::219:b9ff:fe86:690/64 scope link
valid_lft forever preferred_lft forever
=============================================

Notice that wi-fi no longer uses the wlan0 device, but rather eth0. Is this the standar behavior in F17?

Any hints?

rgaelzer · #14 27th August 2012, 02:10 PM

Well, it seems that I found a workaround for this issue.
I kept the b44 module blacklisted in /etc/modprobe.d/broadcom-wl-blacklist.conf, thereby ensuring that the wl module is loaded.
Then, I created the /etc/rc.d/rc.local file with the text

Quote:

#!/bin/sh
exec /usr/sbin/modprobe b44 >/dev/null 2>&1

which loads the b44 module AFTER wl.
In this way, both wl and b44 are correctly loaded by the system.