Bug 954070
| Summary: | rfkill ath9k hard blocked from kernel 3.7 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Wietse Muizelaar <wietse.muizelaar> | ||||||
| Component: | kernel | Assignee: | John Greene <jogreene> | ||||||
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 21 | CC: | alekcejk, awilliam, gansalmon, hhdrewes, itamar, jonathan, jon.dufresne, jones.peter.busi, kernel-maint, linville, lovelylich, madhu.chinakonda, mzotyoka, nathanel.titane, wietse.muizelaar | ||||||
| Target Milestone: | --- | Keywords: | Reopened | ||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2015-12-02 02:46:00 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: | |||||||||
| Attachments: |
|
||||||||
Created attachment 737968 [details]
dmesg output
This big still applies for 3.9.2-200.fc18.x86_64. When you get the hard blocked condition, can you clear it with: rfkill unblock phy0 or does it require rmmod / modprobe to remedy? It requires the rmmod / modprobe to remedy. The exact steps needed are: 1) rmmod 2) suspend-to-ram 3) wait a little 4) resume-from-ram 5) modprobe If the suspend/resume is not in the procedure, it keeps telling the hardware switch (which I don't even have on this system) is disabled. I also tested with the Fedora19 live-CD to see if the problem persists in Fedora19; but unfortunately, it does. Wietse, What is make/model of your laptop? I assume you're certain of this as they can be hard to find on some machines..it would seem reasonable that the later modprobe wouldn't work if a switch DOES exist and was off.. Want to be certain we don't miss something.. Thanks. My laptop is a HP Pavillion G6; type 2003-sd. But an important thing is: I replaced the WiFi adapter to the Atheros AR9280 card (also from HP; but bought from Ebay to replace the kinda sucky original Ralink-device. lspci -v outputs this: 01:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01) Subsystem: Hewlett-Packard Company AR5BHB92-H 802.11abgn Wireless Half-size Mini PCIe Card [AR9280] Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at 52500000 (64-bit, non-prefetchable) [size=64K] Capabilities: [40] Power Management version 2 Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit- Capabilities: [60] Express Legacy Endpoint, MSI 00 Capabilities: [90] MSI-X: Enable- Count=1 Masked- Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00 Kernel driver in use: ath9k Hi! Same issue here on an Acer Aspire 4750 with an Atheros 9287 on a freshly installed Fedora 19. Playing with the modules didn't help. Are there any updates on this issue? Thanks in advance! *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 18 kernel bugs. Fedora 18 has now been rebased to 3.11.4-101.fc18. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 19, and are still experiencing this issue, please change the version to Fedora 19. If you experience different issues, please open a new bug report for those. I did move on to Fedora 19; so changed the version. The bug is still there, on kernel 3.11.3-201.fc19.x86_64 at this moment. I reinstalled Fedora 19 (x86_64 network install from CD) a few times and found, that if the wifi is enabled during the installation, it works fine, but if the wifi is disabled when anaconda starts it can't be enabled and won't work in the installed system as well. Spent a bit of time looking the the mechanism in this area for some other bugs with similar load issue. Hope to find something to assist you as a consequence of that work. Sorry for the delay.. Just installed F20 nightly 11042013 and I can confirm that this bug still remains. I had ben looking for a soluion to the issue since F18 - Wietze's method works indeed by usin rmmod/suspend/modprobe for all the associated ath9k* modules. Linux Mercury 3.11.6-300.fc20.x86_64 #1 SMP Fri Oct 18 22:31:53 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux This seems to be a big regression as I have used this same laptop with F17 and the issue never occurred then. Laptop model - ASUS X75VD-BB51-CB lspci -nn -v: 03:00.0 Network controller [0280]: Qualcomm Atheros AR9485 Wireless Network Adapter [168c:0032] (rev 01) Subsystem: AzureWave Device [1a3b:2c97] Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at f7900000 (64-bit, non-prefetchable) [size=512K] Expansion ROM at f7980000 [disabled] [size=64K] Capabilities: [40] Power Management version 2 Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+ Capabilities: [70] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00 Kernel driver in use: ath9k 04:00.0 Ethernet controller [0200]: Qualcomm Atheros AR8161 Gigabit Ethernet [1969:1091] (rev 10) Subsystem: ASUSTeK Computer Inc. Device [1043:14c7] Flags: bus master, fast devsel, latency 0, IRQ 46 Memory at f7800000 (64-bit, non-prefetchable) [size=256K] I/O ports at d000 [size=128] Capabilities: [40] Power Management version 3 Capabilities: [58] Express Endpoint, MSI 00 Capabilities: [c0] MSI: Enable+ Count=1/16 Maskable+ 64bit+ Capabilities: [d8] MSI-X: Enable- Count=16 Masked- Capabilities: [100] Advanced Error Reporting Capabilities: [180] Device Serial Number ff-78-ee-bc-30-85-a9-ff Kernel driver in use: alx bumping to 20. I tested whether this bug would still be there on F20; downloaded the Live-image and booted the image from USB. Within the F20-live image, I still had to unload the ath9k-module, suspend the laptop, wait a little, resume it, and modprobe ath9k to revive the module. Might be the upstream bug: https://bugzilla.kernel.org/show_bug.cgi?id=66431 *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.13.4-200.fc20. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those. Updated the kernel, rebooted, still seeing this issue. $ rfkill list 0: phy0: Wireless LAN Soft blocked: no Hard blocked: yes 1: asus-wlan: Wireless LAN Soft blocked: no Hard blocked: no $ uname -a Linux localhost.localdomain 3.13.4-200.fc20.x86_64 #1 SMP Thu Feb 20 23:00:47 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux *** Bug 1009241 has been marked as a duplicate of this bug. *** *** Bug 1008123 has been marked as a duplicate of this bug. *** Laptop Asus X551C Fedora 20_x64 Cinnamon 3.13.6-200.fc20.x86_64 Atheros AR9485 Problem still exists temporary solution getting on to the switch off menue using the button "bereitschaft" I think standby switching back on, logging in and Wifi works. A very similar solution on Fedora (which unfortunately has a different module than RHEL) has found fix. The change there is subtly different on rhel and I don't have a device to test the solution here. The fedora bug is https://bugzilla.redhat.com/show_bug.cgi?id=1089731 Lots of info links there to check things too if you wish. To summarize: * WAPF defines the behavior of the Fn+Fx wlan key * The significance of values is yet to be found, but * most of the time: * 0x0 will do nothing * 0x1 will allow to control the device with Fn+Fx key. * 0x4 will send an ACPI event (0x88) while pressing the Fn+Fx key * 0x5 like 0x1 or 0x4 * So, if something doesn't work as you want, just try other values =) */ static uint wapf = 1; module_param(wapf, uint, 0644); MODULE_PARM_DESC(wapf, "WAPF value"); Appears to default to 1, which may not work for your machine.. Try with these three WAPF values, adding them to the kernel command line: The fedora module is asus-nb-wmi, e.g. 1. asus-nb-wmi.wapf=0 2. asus-nb-wmi.wapf=1 3. asus-nb-wmi.wapf=4 e.g. asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75VBP BUT ON RHEL the module is asus-laptop. So, it would appear that would be: asus-laptop.wapf=0 Try the values 0,1, 4, reloading the module after so the change can take effect. You can add this to kernel cmdline, or modprobe -r asus-laptop wapr=1 modprobe asus-laptop wapr=1 put it into a /etc/modproble.d/asus-laptop.conf or other file options asus-laptop wapf=4 Then checkout out rfkill and let me know what you find.. Hope this helps! For my HP laptop, that would be a similar thing with the hp_wmi module? Can you please confirm? Haven't seen it on HP hardware, will need to check that.. Hmm..hp-wmi is your module..It does depend on rfkill, but sadly no keyword to play with.. So no help with this..Haven't given up. Obviously rhel stuff in C21 isn't relevent here. And this might seem not a suspend / resume issue but I'd like to insure this isn't some common issue on asus hardware. 4 (make that 3) Bz's with similar issues: ASUS hardware/rfkill hot key doesn't work and maybe suspend resume.. Chasing a theory.. Well, it isn't a native HP hardware component; I did buy this Atheros mini-pci card myself, and replaced the original (quite crappy) HP card in it. Also, I need to mention I found a slightly different pattern: where I first had to make sure I rmmod-ed the ath9k module, put the machine to suspend, resume, and then modprobe again to make wifi work, I now just have to suspend/resume the machine, and the magic happens. Not sure if this helps with your theory, but wanted to share the information :) I have a possibly similar problem with a Toshiba Qosmio X770. The wifi switch there is a touch-sensitive button that is supposed to light up when the wifi is active. Aside, from that, the button works properly. It's too easy to brush some fingers over the switch and kill the wifi. Furthermore, the light under the key doesn't come on, so it's necessary to notice the connect symbol in the status bar to realize the wifi has been disabled. Comment 21 leads me to hope would be possible to write a startup command that would make sure the wifi is always enabled, or at least give an alert if it's not. I searched https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/platform/x86?id=360f0f39d0c58432574655008ec8dd15e52e1e8d, but I only found a patch for the key's scancode. *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.14.4-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those. Updated kernel, rebooted, same issue. *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.17.2-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21. If you experience different issues, please open a new bug report for those. Updated kernel, rebooted, same issue. Kernel 3.17.2-200.fc20.x86_64. The issue lies within a firmware flag that is not overridden by default for this specific hardware - I use this line in modprobe to reestablish the normal rf state of the wifi for that chipset on my Asus X75VD machines: cat > /etc/modprobe.d/asus-wifi.conf << FILE options asus_nb_wmi wapf=1 FILE Unfortunately, I couldn't find such an option for the ath9k module. The asus-module isn't loaded, since this is an HP laptop. *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.18.7-100.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21. If you experience different issues, please open a new bug report for those. Bug still there with kernel 3.18.7-200.fc21, so also on Fedora 21. *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 21 kernel bugs. Fedora 21 has now been rebased to 3.19.5-200.fc21. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 22, and are still experiencing this issue, please change the version to Fedora 22. If you experience different issues, please open a new bug report for those. After updating the kernel I am no longer experiencing this issue. Marking as resolved. Unfortunately, for me the problem still exists. This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |
Created attachment 737967 [details] lspci outout Description of problem: Since the introduction of kernel 3.7 (both in F17 and after upgrading to F18 the problem persists), my Atheros wireless card is staying in hard blocked state on boot-time. When I unload all the ath9k-modules, suspend my laptop, resume, and modprobe the ath9k module, the hard block is disabled, and wireless networking starts to work. Version-Release number of selected component (if applicable): All kernels starting the first 3.7-kernel. Tested both in Fedora 17 and Fedora 18 (the Fedora 18 LIVE-USB image runs kernel 3.6; and it -does- work, but after installion newer kernels were installed, and it stopped working then). How reproducible: Every time. Steps to Reproduce: 1. Turn on laptop, wait till it boots. 2. Login 3. Unload all the modules (sudo rmmod cfg80211 ath mac80211 ath9k_common ath9k_hw ath9k a coupletimes to make sure the modules are all removed) 4. Close the laptop 5. Wait for a minute 6. Open the laptop again 7. "sudo modprobe ath9k" 8. And wireless network works. Actual results: Afther the firs boot: rfkill tells me this: 1: phy0: Wireless LAN Soft blocked: no Hard blocked: yes Afther the unload-suspend-resume-load, rfkill tells me this: 1: phy0: Wireless LAN Soft blocked: no Hard blocked: no Expected results: To have the wireless card working boot-time. Additional info: lspci output attached. dmesg output attached. The dmesg-output includes the unload-suspend-resume-load output. If any other information is needed, I'm more than willing to provide! Thanks for taking a look into this. Regards, Wietse