Bug 954070 - rfkill ath9k hard blocked from kernel 3.7
Summary: rfkill ath9k hard blocked from kernel 3.7
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 21
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: John Greene
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1008123 1009241 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-04-20 11:00 UTC by Wietse Muizelaar
Modified: 2015-12-02 16:04 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-02 02:46:00 UTC


Attachments (Terms of Use)
lspci outout (5.65 KB, text/plain)
2013-04-20 11:00 UTC, Wietse Muizelaar
no flags Details
dmesg output (74.17 KB, text/plain)
2013-04-20 11:01 UTC, Wietse Muizelaar
no flags Details

Description Wietse Muizelaar 2013-04-20 11:00:52 UTC
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

Comment 1 Wietse Muizelaar 2013-04-20 11:01:34 UTC
Created attachment 737968 [details]
dmesg output

Comment 2 Wietse Muizelaar 2013-05-17 08:19:49 UTC
This big still applies for 3.9.2-200.fc18.x86_64.

Comment 3 John Greene 2013-07-08 17:59:57 UTC
When you get the hard blocked condition, can you clear it with:

rfkill unblock phy0

or does it require rmmod / modprobe to remedy?

Comment 4 Wietse Muizelaar 2013-07-08 18:06:27 UTC
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.

Comment 5 John Greene 2013-07-08 18:51:03 UTC
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.

Comment 6 Wietse Muizelaar 2013-07-08 19:00:17 UTC
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

Comment 7 Zoltán Magyar 2013-10-01 07:20:36 UTC
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!

Comment 8 Justin M. Forbes 2013-10-18 21:13:55 UTC
*********** 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.

Comment 9 Wietse Muizelaar 2013-10-18 21:26:06 UTC
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.

Comment 10 Zoltán Magyar 2013-10-18 22:24:43 UTC
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.

Comment 11 John Greene 2013-10-22 14:58:59 UTC
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..

Comment 12 Nathanel Titane 2013-11-05 16:14:14 UTC
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

Comment 13 Adam Williamson 2013-11-06 20:47:28 UTC
bumping to 20.

Comment 14 Wietse Muizelaar 2013-12-22 20:43:58 UTC
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.

Comment 15 Jon Dufresne 2014-01-19 18:25:55 UTC
Might be the upstream bug:
https://bugzilla.kernel.org/show_bug.cgi?id=66431

Comment 16 Justin M. Forbes 2014-02-24 13:58:33 UTC
*********** 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.

Comment 17 Jon Dufresne 2014-02-26 02:14:12 UTC
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

Comment 18 Jon Dufresne 2014-02-26 02:16:02 UTC
*** Bug 1009241 has been marked as a duplicate of this bug. ***

Comment 19 John Greene 2014-03-04 15:39:46 UTC
*** Bug 1008123 has been marked as a duplicate of this bug. ***

Comment 20 Hermann Drewes 2014-03-27 13:52:35 UTC
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.

Comment 21 John Greene 2014-05-01 19:33:23 UTC
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!

Comment 22 Wietse Muizelaar 2014-05-01 20:08:27 UTC
For my HP laptop, that would be a similar thing with the hp_wmi module? Can you please confirm?

Comment 23 John Greene 2014-05-01 20:24:50 UTC
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..

Comment 24 Wietse Muizelaar 2014-05-01 20:30:35 UTC
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 :)

Comment 25 Peter H. Jones 2014-05-01 20:32:43 UTC
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.

Comment 26 Justin M. Forbes 2014-05-21 19:39:29 UTC
*********** 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.

Comment 27 Jon Dufresne 2014-05-24 01:57:43 UTC
Updated kernel, rebooted, same issue.

Comment 28 Justin M. Forbes 2014-11-13 16:01:28 UTC
*********** 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.

Comment 29 Jon Dufresne 2014-11-14 01:18:50 UTC
Updated kernel, rebooted, same issue. Kernel 3.17.2-200.fc20.x86_64.

Comment 30 Nathanel Titane 2014-12-10 15:34:49 UTC
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

Comment 31 Wietse Muizelaar 2014-12-14 14:12:43 UTC
Unfortunately, I couldn't find such an option for the ath9k module. The asus-module isn't loaded, since this is an HP laptop.

Comment 32 Fedora Kernel Team 2015-02-24 16:22:04 UTC
*********** 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.

Comment 33 Wietse Muizelaar 2015-02-24 21:47:59 UTC
Bug still there with kernel 3.18.7-200.fc21, so also on Fedora 21.

Comment 34 Fedora Kernel Team 2015-04-28 18:32:58 UTC
*********** 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.

Comment 35 Jon Dufresne 2015-04-30 02:24:45 UTC
After updating the kernel I am no longer experiencing this issue. Marking as resolved.

Comment 36 Wietse Muizelaar 2015-05-02 13:09:15 UTC
Unfortunately, for me the problem still exists.

Comment 37 Fedora End Of Life 2015-11-04 12:12:48 UTC
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.

Comment 38 Fedora End Of Life 2015-12-02 02:46:07 UTC
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.


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