Bug 444988 - b43 module 'wireless' light shows incorrect status
Summary: b43 module 'wireless' light shows incorrect status
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 8
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-05-02 16:07 UTC by Max E
Modified: 2008-08-02 23:40 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-06-12 22:45:43 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Requested lspci -vvn (9.53 KB, text/plain)
2008-05-06 09:27 UTC, Max E
no flags Details
hp bitflip fix (2.88 KB, patch)
2008-05-08 14:11 UTC, Michael Buesch
no flags Details | Diff

Description Max E 2008-05-02 16:07:52 UTC
Description of problem:

Could not understand why b43 wireless module did not work on my laptop (Compaq
V5214ea).  Looking at dmesg kept on producing the message:

b43-phy0: Radio hardware status changed to DISABLED

The 'wireless enabled' light was ON, yet the Radio hardware was saying disabled.
Pressed the Wireless enable light on the laptop (light goes off), and suddenly
the Radio hardware was ENABLED.  

Laptop is running Fedora 8 - 2.6.24.5-85.fc8 - running Gnome 2.20.3.

lspci reports: 06:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan
mini-PCI (rev 01)

The network(s) are controlled by NetworkManager.

The logic has been screwed somewhere.  

Version-Release number of selected component (if applicable):
1) b43 firmware is: b43-phy0: Loading firmware version 410.2160 (2007-05-26
15:32:10)


How reproducible:

Everytime

Steps to Reproduce:
1. Start laptop with 2.6.24.5-85.fc8
2. Wireless 'light' on laptop starts at boot time (as specified in
system-config-network-gui
3. Switching 'off' wireless light enables radio (according to dmesg)
  
Actual results:

Wireless light does not correspond to Wireless status

Expected results:

Wireless light ON = Radio ON
Wireless light OFF = Radio OFF

Additional info:

From dmesg:

Registered led device: b43-phy0:tx
Registered led device: b43-phy0:rx
Registered led device: b43-phy0:radio
b43-phy0: Radio hardware status changed to DISABLED
ADDRCONF(NETDEV_UP): wlan0: link is not ready
eth1: no IPv6 routers present
e100: eth1: e100_watchdog: link up, 100Mbps, half-duplex
ADDRCONF(NETDEV_UP): eth1: link is not ready
ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
input: b43-phy0 as /class/input/input12
b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
Registered led device: b43-phy0:tx
Registered led device: b43-phy0:rx
Registered led device: b43-phy0:radio
b43-phy0: Radio hardware status changed to DISABLED
ADDRCONF(NETDEV_UP): wlan0: link is not ready
ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 17
[drm] Initialized drm 1.1.0 20060810
PCI: Setting latency timer of device 0000:00:02.0 to 64
[drm] Initialized i915 1.6.0 20060119 on minor 0
eth1: no IPv6 routers present
nm-system-setti[2445]: segfault at 6d2e6b75 eip 001cf8ac esp bfddd890 error 4
e100: eth1: e100_watchdog: link up, 100Mbps, half-duplex
eth1: no IPv6 routers present
e100: eth1: e100_watchdog: link up, 100Mbps, half-duplex
eth1: no IPv6 routers present
eth1: no IPv6 routers present
b43-phy0: Radio hardware status changed to ENABLED
b43-phy0: Radio turned on by software
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:0f:b5:36:7a:0b
wlan0: authenticate with AP 00:0f:b5:36:7a:0b
wlan0: authenticate with AP 00:0f:b5:36:7a:0b
wlan0: authentication with AP 00:0f:b5:36:7a:0b timed out
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:0f:b5:36:7a:0b
wlan0: authenticate with AP 00:0f:b5:36:7a:0b
wlan0: authenticate with AP 00:0f:b5:36:7a:0b
wlan0: authentication with AP 00:0f:b5:36:7a:0b timed out
eth1: no IPv6 routers present
eth1: no IPv6 routers present
eth1: no IPv6 routers present

Comment 1 John W. Linville 2008-05-02 17:23:29 UTC
Michael, have you heard of such a "reverse polarity" situation with the rfkill 
LED?

Comment 2 Michael Buesch 2008-05-02 18:05:09 UTC
Well, this is easily possible, if the SPROM contains wrong information for the
rfkill LED. There's a bit to flip polarity. Another possibility is that there's
no SPROM value defined for the LED and the hardcoded fallback is not appropriate.
In any case, please do a
cat $(find /sys -name ssb_sprom)
and send the result.

Comment 3 Max E 2008-05-02 18:15:41 UTC
Michael,

As requested - hope this makes sense to you:

0130000064133C100800BE0D00FFFFFF11430080020000000010001800000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0000FFFFFFFFFFFFFFFFFFFFFFFFFFFF1400BDA56AE5FFFFFFFFFFFFFFFFFFFFFFFFFFFF42303D15A0FA79FEFF83FFFF4AFFFFFFFFFFFFFF3EFF494A02FF45440CFFFFFFFFFF021C

Comment 4 Michael Buesch 2008-05-02 18:38:11 UTC
yeah great. Can I have an
lspci -vvn
for the device?

Comment 5 Max E 2008-05-03 11:25:31 UTC
Michael,

Will get back to you on Tuesday 6th, and give you the details then.

Thanks

Max

Comment 6 Max E 2008-05-06 09:27:37 UTC
Created attachment 304611 [details]
Requested lspci -vvn

Comment 7 Michael Buesch 2008-05-08 14:11:49 UTC
Created attachment 304864 [details]
hp bitflip fix

Please try whether this fixes it.

Comment 8 John W. Linville 2008-06-12 18:00:20 UTC
Max are you able to do a build with the patch from comment 7?

Comment 9 Max E 2008-06-12 22:45:43 UTC
Hi John,

An upgrade to F9 seems to have resolved my problem on this front.  I was unable
to build this into F8 [did not know how to do this].  Applogies I cannot
progress this further.

Max


Note You need to log in before you can comment on or make changes to this bug.