Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1152502
Summary: | kernel 3.17 upgrade killed wireless | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Paul Sand <sand.paul> |
Component: | kernel | Assignee: | fedora-kernel-wireless-b43 |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | urgent | Docs Contact: | |
Priority: | unspecified | ||
Version: | 21 | CC: | Anasastu, awilliam, bugzilla, chrissandler, gansalmon, itamar, jonathan, jrimpo, kernel-maint, larry.finger, linville, madhu.chinakonda, mchehab, p.erdelyi, sgallagh |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | AcceptedFreezeException | ||
Fixed In Version: | kernel-3.17.1-302.fc21 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-10-21 18:03:45 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1043127 |
Description
Paul Sand
2014-10-14 10:22:05 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. 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. (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. 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. 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. 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 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? Jeremy, no you have entirely different hardware. Your issue is different. @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? 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. 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. 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). (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. 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." 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. 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. 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. I'm +1 FE for this. +1 FE +1 FE That's +4, marking as acceptedFE. 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. 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). When you try to use b43, what do you see in the output of the dmesg command? 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 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. 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! 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. |