Bug 57581
Summary: | b43 wireless no longer works, MacBook Pro | ||
---|---|---|---|
Product: | Drivers | Reporter: | Josh Ernzen (jpe.1337) |
Component: | Network | Assignee: | drivers_network (drivers_network) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | johannes, jpe.1337, kernel, kurt, sntmail, UweBreidenbach, zajec5 |
Priority: | P1 | ||
Hardware: | x86-64 | ||
OS: | Linux | ||
Kernel Version: | 3.8+ | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
Config file for the working kernel
Config file for the kernel that does not work Config file for the kernel that does not work Config file for the kernel that does not work Full lspci output iw wlan0 scan -u output |
Description
Josh Ernzen
2013-05-05 03:43:32 UTC
Created attachment 101481 [details]
Config file for the working kernel
Configuration file for 3.7.10
Created attachment 101491 [details]
Config file for the kernel that does not work
Configuration file for 3.9.2
Still does not work for 3.9.2 Created attachment 101501 [details]
Config file for the kernel that does not work
Configuration file for 3.9.2
Created attachment 101511 [details]
Config file for the kernel that does not work
Configuration file for 3.9.2
I did have CONFIG_CFG80211_DEFAULT_PS turned on but it didn't work, I tried turning it off to see if that could have been causing my issue. Both tries did not work. Downstream bug at https://bugs.gentoo.org/show_bug.cgi?id=466920 Created attachment 107046 [details]
Full lspci output
I have a similar issue on my Lenovo S12. I'am using Gentoo Linux with b43-fwcutter-017", b43-firmware-5.100.138 and '03:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g LP-PHY (rev 01)' (see attachment above for full lspci output). I bisected git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git and got the following commit: 0172bb75073e11a5aa9d8a953bdaefb8709f00c8 is the first bad commit commit 0172bb75073e11a5aa9d8a953bdaefb8709f00c8 Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Nov 23 14:23:30 2012 +0100 I have the same problem with my pcmcia card: 02:00.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03) A bisect also returned the same commit for me. It doesn't seem to try to assosiate anymore to the AP anymore. Does this problem happen on specific networks, or generally? (In reply to Johannes Berg from comment #11) > Does this problem happen on specific networks, or generally? I've only tried this on my home network which uses channel 1 and WEP if this is relevant. (In reply to Johannes Berg from comment #11) > Does this problem happen on specific networks, or generally? I have configured a wpa2-psk and a wpa2-enterprise network, but my driver doesn't even scan anymore, so the configuration doesn't matter at all. I thought that for me iwlist scan still returned things, it's just that it doesn't seem to try to associate. (In reply to Kurt Roeckx from comment #14) > I thought that for me iwlist scan still returned things, it's just that it > doesn't seem to try to associate. You are right. I thought so, because NetworkManager doesn't show the scanned networks, but 'iwlist scan' still scans. Can you attach the "iw wlan0 scan -b -u" info (for the APs you'd like to connect to)? (In reply to Johannes Berg from comment #16) > Can you attach the "iw wlan0 scan -b -u" info (for the APs you'd like to > connect to)? Best on a working kernel, or even better on both working/non-working actually (In reply to Johannes Berg from comment #17) > (In reply to Johannes Berg from comment #16) > > Can you attach the "iw wlan0 scan -b -u" info (for the APs you'd like to > > connect to)? > > Best on a working kernel, or even better on both working/non-working actually What is the purpose of the -b option? I couldn't find it in my iw utilities. So I just attach 'iw wlan0 scan -u'. Created attachment 107197 [details]
iw wlan0 scan -u output
iw wlan0 scan -u output of working and non working kernel
(In reply to Uwe Breidenbach from comment #19) > iw wlan0 scan -u output of working and non working kernel Well, they both have exactly the same output, and it all matches (channel 5 = 2432 MHz) so I really don't see how commit a024de28e44d04637de9bb0506189e2238c6ef2e could be causing a connectivity problem? Besides, mac80211 has always used the DS IE, but it doesn't even mismatch... I think your bisect was probably not quite right. The bisect was right. But maybe it's not (directly) a kernel bug. I tried to connect via wpa_supplicant separately and I got a connection. But NetworkManager (version 0.9.6.4 and 0.9.8.2-r3), which uses wpa_supplicant, neither show any wireless networks nor connect to the configured ones. So why could the NetworkManager have a problem with this commit? Was there an API change? And why are only some b43 devices affected? Have you tried reverting that commit? I don't know if it's possible, but I don't really see how that would have changed behaviour ... Are you using wireless extensions with wpa_supplicant by any chance? I'm grasping at straws though - as far as I checked the iw scan output was completely identical. Can you debug the supplicant? See https://wiki.gnome.org/NetworkManager/Debugging#Debugging_wpa_supplicant_0.7_and_later For me "iw wlan0 scan" doesn't produce any output on the broken version, but does work on the working version. iwlist wlan0 scan works on both I would also like to point out that we were with 2 that found the same commit id to be the first broken version. I'm not using network manager or wpa_supplicant. I just use iwconfig to set the essid and the WEP key. I've tracked similar problem and reported it in: http://lists.infradead.org/pipermail/b43-dev/2013-March/003003.html Then ZHAO fixed this problem in commit: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=64e5acb09ca6b50c97299cff9ef51299470b29f2 I've tested it and confirmed the fix in: http://lists.infradead.org/pipermail/b43-dev/2014-January/003334.html Fix is preset in kernel 3.14 and all newer ones. It was also commited to many stable kernels: 3.2.56 3.4.79 3.10.29 3.12.10 3.13.2 Please try one of the kernels with the fix included. *** Bug 60798 has been marked as a duplicate of this bug. *** |