Bug 622114 (J.Stingl) - Atheros AR5001 wlan not connecting due to rfkill
Summary: Atheros AR5001 wlan not connecting due to rfkill
Keywords:
Status: CLOSED WORKSFORME
Alias: J.Stingl
Product: Fedora
Classification: Fedora
Component: rfkill
Version: 13
Hardware: x86_64
OS: Linux
low
high
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Kernel-QE - Hardware
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-07 11:49 UTC by drstingl
Modified: 2015-03-19 18:14 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-09-21 21:16:48 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 478036 0 None None None Never

Description drstingl 2010-08-07 11:49:51 UTC
Description of problem:

My laptop is a Asus X50 with Atheros AR5001 wlan chip.
After upgrade from Fedora 11 to 13 wlan does not work any more due to problem with rfkill.

Output:

>rfkill list
0: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: yes

Flipping the wlan switch results in 

>rfkill list
0: phy0: Wireless LAN
	Soft blocked: yes
	Hard blocked: yes

Hardware block cannot be released this way. 'rfkill unblock all' also just switches the soft block. 

Further info:
>lspci -vv
02:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless Network Adapter (rev 01)
	Subsystem: Device 1a3b:1026
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at fdff0000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: <access denied>
	Kernel driver in use: ath5k
	Kernel modules: ath5k



How reproducible:
Always happening. No solution found. Found similar bug in ubuntu: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/478036 

Steps to Reproduce:
1.switch laptop on :)

Any more output I can collect?
Thanks

Comment 1 drstingl 2010-08-07 12:11:53 UTC
I overlooked the procedure done by the ubuntu user to solve his problem. After I did the same thing myself I was able to activate the wlan device (hard block had gone)

The steps were:
1. kill process /usr/libexec/hal/hald-addon-rfkill-killswitch
2. modprobe -r -f ath5k
3. modprobe ath5k

as a result rfkill list showed:
1: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no

Comment 2 John W. Linville 2010-08-09 14:49:43 UTC
Are the modprobes necessary?  What does 'rfkill list' show after only killing hald-addon-rfkill-killswitch?

Comment 3 drstingl 2010-08-10 10:08:19 UTC
I cannot answer that since I cannot reproduce the hard blocked state. When I boot the system now it has hard and soft block turned off and soft block is switchable by either flipping a switch or by using rfkill.

I'm not sure if this is really a bug or an error which occured during upgrading from F11 to 13.

Comment 4 John W. Linville 2010-08-10 18:27:58 UTC
I'm going to close this for now, based on comment 3.  If you experience this issue again, please reopen this bug...thanks!

Comment 5 drstingl 2010-08-10 19:58:10 UTC
I just started the laptop again after having booted into Vista and turned off wlan (by wlan switch). Now hard block was off and soft block on.

After I flipped the switch, hard block was on and soft off. Further flipping only changed soft block status.

Procedure as in Comment 1 worked again. Modprobes were necessary because after killing hald-addon-rfkill-killswitch the hard block was still on.

I don't have the time right now to check whether the vista issue had something to do with it but will do it tomorrow...

Comment 6 John W. Linville 2010-08-24 17:52:05 UTC
What sort of laptop is this?

Comment 7 Bob Copeland 2010-08-24 19:30:05 UTC
from original post, ASUS x50 :)

Comment 8 John W. Linville 2010-08-24 19:39:22 UTC
Ah, yes... :-)

Does blacklisting asus-laptop and/or manipulating the wlan_status option of asus-laptop affect this issue?

Comment 9 drstingl 2010-08-25 08:52:42 UTC
The problem persists, although I cannot pinpoint what causes it initially. If I only use Fedora it seems to be alright and the hard block doesn't switch on.

If I use Vista in between it sometimes switches the hard block to on, but not always.

I cannot really say which steps are necessary to reproduce this problem.

Comment 10 drstingl 2010-08-25 08:54:34 UTC
btw how do I change the 'wlan-status option' you mentioned and/or blacklist asus-laptop?

Comment 11 John W. Linville 2010-08-25 15:34:57 UTC
Add a line like this to a file called /etc/modprobe.d/asus-laptop.conf:

options asus-laptop wlan_status=0

Other possible values are 1 and -1 -- please experiment with those as well.

For blacklisting, add a line like this to /etc/modprobe.d/blacklist.conf:

blacklist asus-laptop

When testing this options, you will need to boot to the other OS and then back into Linux.  Do any of these options effect the situation?

Comment 12 drstingl 2010-08-30 09:26:33 UTC
I was unable to spend much time on the issue over the weekend. Booting and rebooting takes quite some time.
Anyhow: I couldn't reproduce the aforementioned problem exactly but had some issues nonetheless.
If I set the wlan switch to off in Vista and reboot into Fedora, rfkill reports both locks to be off (when Fedora had been active before Vista it had had connection to the wlan and both blocks off so I assume Fedora didn't check  this again at boot time). But NM doesn't connect to the wlan and doesn't ask for a passphrase to my wlan-key. 
When the wlan switch is flipped (to the wlan-on state), rfkill shows a soft block. This can be removed by 'rfkill unblock all'. The NM then asks for the passphrase and connects to the wlan.

I don't know if this is in any way related to the initially reported bug. That one only happens occasionally and I haven't found a way to reproduce it consistently.

I wasn't able to experiement with the blacklisting procedure due to time issues but hopefully I can check it out in the next days.

Comment 13 John W. Linville 2010-09-15 18:00:08 UTC
Any word on the blacklisting?

Comment 14 drstingl 2010-09-16 14:37:27 UTC
I cannot report anything new here. There was no time to check on this bug due to my work and secondly, after I upgraded to the lastest kernel, the whole system is messed up and I haven't gotten around to fix it.

If I can resolve the issues with the current kernel I might get back to the bug but it won't happen in the next weeks since I simply lack the time...

Comment 15 drstingl 2010-09-21 21:17:12 UTC
Cannot reproduce bug.


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