Red Hat Bugzilla – Bug 251233
bcm43xx_mac80211 module failing to activate hardware
Last modified: 2007-11-30 17:12:12 EST
Description of problem:
I have a Dell laptop with a Broadcom wireless card, described by lspci
as "Broadcom Corporation Dell Wireless 1390 WLAN Mini-PCI Card". I installed
the firmware using fwcutter.
The bcm43xx_mac80211 module loads and uses the firmware, and knetworkmanager
recognises the existence of the card - but nothing at all works. "dmesg"
contains the message that the radio is inactive:
bcm43xx_mac80211: Loading firmware version 351.126 (2006-07-29 05:54:02)
ssb: Switching to ChipCommon core, index 0
ssb: Switching to IEEE 802.11 core, index 1
bcm43xx_mac80211: Broadcom 4311 WLAN found
ssb: Switching to IEEE 802.11 core, index 1
bcm43xx_mac80211: Found PHY: Analog 4, Type 2, Revision 8
bcm43xx_mac80211: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
bcm43xx_mac80211: Radio turned off
wmaster0: Selected rate control algorithm 'simple'
On the laptop LEDs, the "WIFI" LED never lights up. Under Windows Vista, it
lights up when the computer is booted into Windows.
Version-Release number of selected component (if applicable):
(2.6.22 doesn't boot on this laptop...)
How reproducible: Every time
Actual results: No wifi.
Expected results: Wifi!
I've now successfully booted the 184.108.40.206-41.fc7 kernel and confirm that the
same problem exists.
Is this issue about the LED? Does the device connect to the network?
Also, please try the latest available F7 kernel -- there have been many
improvements lately. Does the problem persist?
No, it's not the LED... the device doesn't do anything at all.
I was assuming that the message in "dmesg" which says that the radio is turned
off by the hardware had something to do with it, and that the lack of LED was
a symptom of this. I mentioned that the LED lights on Windows as evidence that
the card does work when driven correctly.
I've tried the latest F7 kernel - no change.
I presume there is a button for enabling/disabling the wireless (like when on
an airplane). Have you tried pushing that button? FWIW, some of those
buttons are just momentary switches and so only send an event to the driver
when pushed (i.e. that fact that it was on under windows doesn't necessarily
mean it is still "on").
You might also google for your laptop model and "rf kill" or "rfkill" -- some
laptops need special little helper programs to get the wireless enabled. I'm
sorry I can't be more specific -- Broadcom and the laptop vendors aren't
exactly helpful in this regard.
Does any of the above help?
I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.
I am CC'ing myself to this bug and will try and assist you in resolving it if I can.
There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?
If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.
There's no physical button on the laptop.
Googling for Dell Inspiron rfkill/ rf kill Bcm in various combinations did not
bring me anything helpful.
Please advise of what else I can do to help you track this bug.
Sorry, I forgot to mention that it's a Dell Inspiron *1501* and I googled on
that term too.
I think Fn+F2 is the magic combo? It should have a symbol like the one here:
Thanks, Christopher, for that- Fn+F2 does seem to be the magic combo. The
light comes on, and a message appears in dmesg to tell me that the hardware
has been activated.
I'm not near an access point right now so am not sure if it's working, but
I'll let you know as soon as I can.
However, when the hardware is activated, I get this in my /var/log/messages
every 6 seconds:
Oct 5 19:10:09 hodge NetworkManager: <info> Error getting killswitch power:
org.freedesktop.Hal.Device.UnknownError - An Error occurred. The Error message
is: Could not open file /sys/devices/platform/dcdbas/smi_data. Check that
dcdbas driver is properly loaded.
"modprobe dcdbas" stops this from happening, but I don't know what I've done
by doing that, or if it's meant to be done automatically somehow. Please
In my opinion, the bcm43 driver ought to automatically activate the hardware
if it's not already activated, by default. Otherwise clueless users like me
who haven't figured out the magic keypresses will think their drivers are
Glad you found the killswitch combo. I'm not sure why dcdbas was not loaded
for you automatically -- you may want to open a bug for that one.
As for turning it on by default, the counter argument is that clueless users
might not deactivate their wireless on airplanes. Anyway, in many/most cases
the killswitch does something outside of the software's control (as it
probably should be). IOW b43 probably can't do it at all.
Please try the wireless ASAP and let us know the results now that you can
operate the killswitch...thanks!
Wireless works (at least, it detected some real networks). Thanks for all the
help. (I think that software alone can activate the wifi in this case, because
Windows manages to do it, which is why I assumed that the bcm Linux driver was
Do you want to re-assign this bug to HAL, or whatever component should be
auto-loading the dcdbas module?
Please open a new bug for the dcdbas problem...thanks!