Bug 1152502 - kernel 3.17 upgrade killed wireless
Summary: kernel 3.17 upgrade killed wireless
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 21
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: fedora-kernel-wireless-b43
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException
Keywords:
Depends On:
Blocks: F21BetaFreezeException
TreeView+ depends on / blocked
 
Reported: 2014-10-14 10:22 UTC by Paul Sand
Modified: 2014-12-27 20:49 UTC (History)
15 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2014-10-21 18:03:45 UTC


Attachments (Terms of Use)

Description Paul Sand 2014-10-14 10:22:05 UTC
Description of problem:

recent upgrade of kernel from kernel-3.16.3-302.fc21.x86_64
to kernel-3.17.0-300.fc21.x86_64 caused wireless card to not
work any more. Same with kernel-3.17.0-301.fc21.x86_64

Version-Release number of selected component (if applicable):

kernel-3.17.0-300.fc21.x86_64 & kernel-3.17.0-301.fc21.x86_64

How reproducible:

wireless networking fails after rebooting to new kernel;
rebooting to 3.16 kernel restores function.

Steps to Reproduce:
1. reboot to 3.17 kernel, wireless fails
2. reboot to 3.16 kernel, wireless works
3.

Actual results:

wireless not working under 3.17

Expected results:

wireless working under 3.17

Additional info:

# lspci -vnn -d 14e4:
4:02.0 Network controller [0280]: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller [14e4:4318] (rev 02)
	Subsystem: Linksys WMP54GS v1.1 802.11g Wireless-G PCI Adapter with SpeedBooster [1737:0042]
	Flags: bus master, fast devsel, latency 64, IRQ 18
	Memory at f7afe000 (32-bit, non-prefetchable) [size=8K]
	Kernel driver in use: b43-pci-bridge
	Kernel modules: ssb

Under 3.16, "dmesg --notime | grep b43" gives
b43-phy0: Broadcom 4318 WLAN found (core revision 9)
b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
b43-phy0 warning: 5 GHz band is unsupported on this PHY
b43-phy0: Loading OpenSource firmware version 410.31754
b43-phy0: Hardware crypto acceleration not supported by firmware
b43-phy0: Loading OpenSource firmware version 410.31754
b43-phy0: Hardware crypto acceleration not supported by firmware
b43-phy1: Broadcom 4318 WLAN found (core revision 9)
b43-phy1: Found PHY: Analog 3, Type 2 (G), Revision 7
b43-phy1 warning: 5 GHz band is unsupported on this PHY
b43-phy1: Loading OpenSource firmware version 410.31754
b43-phy1: Hardware crypto acceleration not supported by firmware
b43-phy1: Loading OpenSource firmware version 410.31754
b43-phy1: Hardware crypto acceleration not supported by firmware
b43-phy1: Loading OpenSource firmware version 410.31754
b43-phy1: Hardware crypto acceleration not supported by firmware
b43-phy2: Broadcom 4318 WLAN found (core revision 9)
b43-phy2: Found PHY: Analog 3, Type 2 (G), Revision 7
b43-phy2 warning: 5 GHz band is unsupported on this PHY
b43-phy2: Loading OpenSource firmware version 410.31754
b43-phy2: Hardware crypto acceleration not supported by firmware
b43-phy3: Broadcom 4318 WLAN found (core revision 9)
b43-phy3: Found PHY: Analog 3, Type 2 (G), Revision 7
b43-phy3 warning: 5 GHz band is unsupported on this PHY
b43-phy3: Loading OpenSource firmware version 410.31754
b43-phy3: Hardware crypto acceleration not supported by firmware

Under 3.17, the same command:
b43-phy0: Broadcom 4318 WLAN found (core revision 9)
b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 3, Type 2 (G), Revision 7)
b43: probe of ssb0:0 failed with error -95

Comment 1 Paul Sand 2014-10-14 18:59:11 UTC
On this page: http://forum.siduction.org/index.php?topic=5020.0

the poster seemed to have the same problem with his distribution (Siduction),
and (today) claims to see things working again with the distribution's
"3.17-3" kernel.

Comment 2 Lori 2014-10-15 19:43:50 UTC
If the latest kernel doesn't work, the problem could be due to a lack of kmod-wl. On some systems, it's necessary to have the appropriate kmod-wl packages for the kernel being used. Otherwise wireless would fail.

On my laptop, I'm running:
kernel.i686                                  3.16.4-200.fc20

And have the following kmod-wl packages:
kmod-wl.i686                           6.30.223.248-3.fc20.1
kmod-wl-3.16.4-200.fc20.i686.i686      6.30.223.248-3.fc20.1

I also have two backup kernels, and thus two more kmod-wl-[KERNELVERSION] packages that aren't listed above.

Comment 3 Paul Sand 2014-10-17 13:46:12 UTC
(In reply to Lori from comment #2)
> If the latest kernel doesn't work, the problem could be due to a lack of
> kmod-wl. On some systems, it's necessary to have the appropriate kmod-wl
> packages for the kernel being used. Otherwise wireless would fail.

I found kmod-wl in the RPMFusion nonfree repository. A little tricky to download it under the 3.16 (wireless-working) kernel, but then install under the 3.17 (wireless-nonworking) kernel.

It seemed to install OK (I see the "wl" module when I do the lsmod command)
but did not recognize my chipset (BCM4318). This page: 

http://www.cyberciti.biz/faq/fedora-linux-install-broadcom-wl-sta-wireless-driver-for-bcm43228/

does not list BCM4318 as one of the supported chipsets, so maybe that's not surprising.

I think even if it did work, this should still be considered a kernel bug, since there's a clear regression from the 3.16 kernel.

Comment 4 Larry Finger 2014-10-17 16:00:49 UTC
The BCM43228 is an 802.11n chip, whereas BCM4318 is 802.11g. The former should not reference the latter.

Please post your .config. If this is a prebuilt kernel, it can likely be found at /proc/config.gz. I do not think this is a kernel bug/regression, but I really suspect a configuration problem. In particular, look for the value of CONFIG_B43_PHY_G. It *must* be "y". This is a new parameter that was added in June 2014. Previously, this functionality was always present, but it is now possible to not include it so as to make the kernel as small as possible.

Comment 5 Josh Boyer 2014-10-17 16:05:22 UTC
Sigh.  OK, the B43_PHY_G issue is probably the problem.  It isn't set in our config.  I'll try and get that fixed today.  Thank you for the quick response Larry.

Comment 6 Fedora Update System 2014-10-18 00:24:47 UTC
kernel-3.17.1-302.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/kernel-3.17.1-302.fc21

Comment 7 Jeremy Rimpo 2014-10-18 08:53:56 UTC
In my case, with a Realtek RTL8723AE, I'm having intermittent failure. It seems if I reboot from a working system - I maintain functionality. However, a reboot from the affected system seems to disable the antennae and I no longer see any available networks.

Is this the same issue?

Comment 8 Josh Boyer 2014-10-18 13:15:46 UTC
Jeremy, no you have entirely different hardware.  Your issue is different.

Comment 9 Larry Finger 2014-10-18 18:33:40 UTC
@Jeremy: You do need to open a separate issue; however, the maintainer of this driver (Jes Sorensen, RedHat in Belgium) is aware of some reports that doing a warm reboot from Windows results in a non-working RTL8723AU. If you power off and then reboot, does that help?

Comment 10 Jeremy Rimpo 2014-10-18 19:41:31 UTC
It's actually not a warm reboot from windows - but rather from my working copy of 21 with the recent kernels. It actually works every time from a warm boot from Windows. Cold boots do not guarantee a working wifi in this case.

I'm working on a different issue currently, but I'll open a ticket soon.

Comment 11 Jeremy Rimpo 2014-10-18 22:44:35 UTC
I gave the 3.17.1-302 update a try, and a quick run seemed better. I need to run a more thorough set of testing to be sure. My system was suffering from some of the kernel oops bugs relating to the nouveau driver, so that may have been a contributing factor. I'll let you know when I'm sure.

Comment 12 Fedora Update System 2014-10-19 02:32:55 UTC
Package kernel-3.17.1-302.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.17.1-302.fc21'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-13222/kernel-3.17.1-302.fc21
then log in and leave karma (feedback).

Comment 13 Paul Sand 2014-10-19 10:11:39 UTC
(In reply to Fedora Update System from comment #12)
> Package kernel-3.17.1-302.fc21:
> * should fix your issue,

Yes it did. Thanks very much to all involved.

Comment 14 Fedora Blocker Bugs Application 2014-10-21 00:15:56 UTC
Proposed as a Freeze Exception for 21-beta by Fedora user chr77 using the blocker tracking app because:

 Network hardware needs to work to be able to apply updates.

"The installed system must be able to download and install updates with the default graphical package manager in all release-blocking desktops."

Comment 15 Adam Williamson 2014-10-21 00:56:22 UTC
for the record, jwboyer also wanted us to pull 3.17.1-302 into Beta as the latest 3.17 bugfix build, I've asked him to chip in somehow if he has other bugs to point to as justification as well.

Comment 16 Josh Boyer 2014-10-21 01:15:17 UTC
There are another handful of btrfs corruption fixes that people need and there's an ext4 CVE fix as well.  Simply making note for the FE, not anything to do with this actual bug.

Comment 17 Adam Williamson 2014-10-21 16:35:37 UTC
I'm +1 FE to 3.17.1-302 sort of for the combination of things - this bug, the CVEs, btrfs fixes, and just generally having the latest upstream fixes from 3.17.1, it seems likely to be an improvement and relatively easy to lift out if not.

Comment 18 Stephen Gallagher 2014-10-21 16:39:07 UTC
I'm +1 FE for this.

Comment 19 Kevin Fenzi 2014-10-21 16:40:08 UTC
+1 FE

Comment 20 Chris Murphy 2014-10-21 16:40:21 UTC
+1 FE

Comment 21 Adam Williamson 2014-10-21 17:10:58 UTC
That's +4, marking as acceptedFE.

Comment 22 Fedora Update System 2014-10-21 18:03:45 UTC
kernel-3.17.1-302.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 23 peter 2014-12-27 18:30:09 UTC
Same here, kernel 3.17.7-300.fc21.i686. Network doesn't work any more. When I install broadcom-wl and reboot, I don'see the APs any longer in NetworkManager. I've deinstalled broadcom-wl again. Now I'm using the notebook via android tablet (usb tethering).

Comment 24 Larry Finger 2014-12-27 18:36:39 UTC
When you try to use b43, what do you see in the output of the dmesg command?

Comment 25 peter 2014-12-27 18:50:40 UTC
dmesg:
[   37.907731] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[   37.967559] ip6_tables: (C) 2000-2006 Netfilter Core Team
[   38.071625] Ebtables v2.0 registered
[   38.125116] Bridge firewalling registered
[   42.328213] IPv6: ADDRCONF(NETDEV_UP): p1p1: link is not ready
[   42.433047] b43-phy0: Loading OpenSource firmware version 410.31754
[   42.433056] b43-phy0: Hardware crypto acceleration not supported by firmware
[   42.483116] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   82.399437] Bluetooth: Core ver 2.19
[   82.399843] NET: Registered protocol family 31
[   82.399846] Bluetooth: HCI device and connection manager initialized
[   82.399859] Bluetooth: HCI socket layer initialized
[   82.399863] Bluetooth: L2CAP socket layer initialized
[   82.399875] Bluetooth: SCO socket layer initialized
[   82.462871] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   82.462876] Bluetooth: BNEP filters: protocol multicast
[   82.462889] Bluetooth: BNEP socket layer initialized
[  107.537507] fuse init (API version 7.23)

/var/log/messages
Dec 27 19:34:40 localhost kernel: cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
Dec 27 19:34:40 localhost kernel: cfg80211:   (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
Dec 27 19:34:40 localhost kernel: cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
Dec 27 19:34:40 localhost kernel: cfg80211:   (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
Dec 27 19:34:40 localhost kernel: cfg80211:   (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
Dec 27 19:34:40 localhost kernel: cfg80211:   (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
Dec 27 19:34:40 localhost kernel: cfg80211:   (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
Dec 27 19:34:40 localhost kernel: cfg80211:   (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
Dec 27 19:34:40 localhost kernel: b43-phy0: Broadcom 4318 WLAN found (core revision 9)
Dec 27 19:34:40 localhost kernel: b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
Dec 27 19:34:40 localhost kernel: b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0
Dec 27 19:34:40 localhost kernel: Broadcom 43xx driver loaded [ Features: PMNLS ]
Dec 27 19:34:40 localhost kernel: b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
Dec 27 19:34:40 localhost kernel: b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
Dec 27 19:34:40 localhost kernel: b43 ssb0:0: Direct firmware load for b43-open/pcm5.fw failed with error -2

Comment 26 Larry Finger 2014-12-27 19:18:43 UTC
The following shows that you have not installed the firmware:

Dec 27 19:34:40 localhost kernel: b43 ssb0:0: Direct firmware load for
b43/ucode5.fw failed with error -2
Dec 27 19:34:40 localhost kernel: b43 ssb0:0: Direct firmware load for
b43/ucode5.fw failed with error -2
Dec 27 19:34:40 localhost kernel: b43 ssb0:0: Direct firmware load for
b43-open/pcm5.fw failed with error -2

I am not a Fedora user, but I think you need to:

sudo yum install b43-fwcutter wget
wget http://www.lwfinger.com/b43-firmware/broadcom-wl-5.100.138.tar.bz2
tar xjf broadcom-wl-5.100.138.tar.bz2
sudo b43-fwcutter -w /lib/firmware broadcom-wl-5.100.138/linux/wl_apsta.o

You will need Internet access for these to work.

Comment 27 peter 2014-12-27 19:54:57 UTC
Thx:) I'm just wondering, how it could happen. The network worked three days ago just fine. Than I made an update to the firmeware of the fritz.box. While the update process the connection was broken and could not be restored. All other computer, tablets and smartphones worked without problems.
I also use to make daily updates, and there were kernel updates in the last few days. I was not sure. 
Once again many thanks!

Comment 28 Larry Finger 2014-12-27 20:49:04 UTC
Neither a kernel update, nor a change in the firmware of the AP should cause the firmware files to be deleted. It would happen if you had to scrub the partition for / and reinstall Fedora, or if you switched from wl to b43, and had not used b43 before. It is certainly possible that wl cannot handle the new Fritz.Box firmware.

The files in /lib/firmware will persist through a kernel or even a Fedora update, but not a new install.


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