Bug 29132 - phy0 rfkill stuck in hard blocked: yes
phy0 rfkill stuck in hard blocked: yes
Status: CLOSED INVALID
Product: Drivers
Classification: Unclassified
Component: network-wireless
All Linux
: P1 normal
Assigned To: drivers_network-wireless@kernel-bugs.osdl.org
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-14 20:32 UTC by Orion Poplawski
Modified: 2011-03-14 14:22 UTC (History)
4 users (show)

See Also:
Kernel Version:
Tree: Fedora
Regression: Yes


Attachments

Description Orion Poplawski 2011-02-14 20:32:34 UTC
HP EliteBook 8730w BIOS Version: F.11
03:00.0 Network controller: Intel Corporation Ultimate N WiFi Link 5300

# rfkill list
0: hp-wifi: Wireless LAN
        Soft blocked: no
        Hard blocked: no
1: hp-bluetooth: Bluetooth
        Soft blocked: no
        Hard blocked: no
2: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: yes

There seems to be nothing I can do to hard unblock phy0.

Tested with:
2.6.35.10-74.fc14.x86_64
2.6.35.11-83.fc14.x86_64
2.6.38-0.rc4.git0.1.fc15.x86_64

This was working okay (though perhaps with some manual rfkill munging) with the last Fedora 12 kernels.  I'll be moving back to F13 soon.
Comment 1 Orion Poplawski 2011-02-14 20:37:33 UTC
pressing the hardware switch toggles the two hp-* kill switcheds, but doesn't affect phy0.
Comment 2 John W. Linville 2011-02-17 22:31:34 UTC
What about 'rfkill unblock all'?
Comment 3 Orion Poplawski 2011-02-22 18:23:55 UTC
Same:

[root@adelie ~]# rfkill unblock all
[root@adelie ~]# rfkill list
0: hp-wifi: Wireless LAN
        Soft blocked: no
        Hard blocked: no
1: hp-bluetooth: Bluetooth
        Soft blocked: no
        Hard blocked: no
2: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: yes
Comment 4 John W. Linville 2011-02-22 18:33:33 UTC
Are you absolutely certain that there is not a separate rfkill switch, perhaps along the outside edge of the laptop when closed?  Many laptops have slider switches like this that accidentally get flipped.

Barring that, can you use 'git bisect' to determine which commit causes this issue for you?
Comment 5 Orion Poplawski 2011-02-22 18:47:40 UTC
There is a physical kill switch.  Pressing that toggles the hp-wifi and hp-bluetooth kill switches, but phy0 is stuck off.  I'm not going to be able to run git bisect on this machine unfortunately.
Comment 6 wey-yi.w.guy 2011-02-22 19:56:35 UTC
could you try the following patch to see if it help?

commit 3dd823e6b86407aed1a025041d8f1df77e43a9c8
Author: Don Fry <donald.h.fry@intel.com>
Date:   Sun Feb 6 09:29:45 2011 -0800
iwlagn: Re-enable RF_KILL interrupt when down


Wey
Comment 7 jakob gruber 2011-03-13 11:28:27 UTC
I've been fighting with an issue that seems very similar. On an Acer Aspire 4520 with an Atheros AR5001 Wireless Network Adapter, kernel 2.6.37.3, sometimes rfkill seemed to get stuck in 'Hard blocked: yes'. Pressing the wlan switch (it's a soft toggle, not a physical slider) seemed to toggle only 'Soft blocked' and it was impossible to actually get the card running again.

I think I've now figured out what actually happens: when booting with an enabled wlan (= disabled rfkill), switching between blocked and unblocked states works without problems. When booting with wlan disabled (= rfkill enabled), toggling the wlan switch does NOT take effect immediately, but only after REBOOTING the computer. Un- and reloading ath5k does not help. This leads to very confusing situations where it sometimes works, sometimes it doesn't, and nobody knows how to reproduce the issue.


Here's a walkthrough of the entire procedure, starting with a session that has wlan enabled and everything working.

Initial state:
0: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no

After toggling wlan switch the first time:
0: phy0: Wireless LAN
	Soft blocked: yes
	Hard blocked: no

After toggling wlan switch the second time:
0: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no

Note that wlan works at this point as expected. The first toggle disabled it, the second reenabled it.

What I will do now is toggle the switch one more time (which will disable the wlan) and reboot the computer.

After the reboot, wlan does NOT work. However, rfkill lists the following:
0: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no
ifconfig shows the interface as up. iwlist wlan0 scan returns with 'No scan results'. 

After pressing the wlan switch once:
0: phy0: Wireless LAN
	Soft blocked: yes
	Hard blocked: no

After pressing it a second time (notice the Hard block):
0: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: yes

A third time:
0: phy0: Wireless LAN
	Soft blocked: yes
	Hard blocked: yes

Subsequent presses only switch between the previous 2 states. The wlan doesn't work at any point during this. Trying to put wlan0 up with ifconfig returns 'SIOCSIFFLAGS: Operation not possible due to RF-kill'.

*However*, after rebooting, the wlan switch action takes effect. 
This means that an even number of wlan toggles will result in a blocked (= nonworking) state, and an odd number of wlan toggles will result in an unblocked state.

I was able to reproduce this 100% of the time once I actually figured out what was going on.

If you need more info please let me know.

PS:
This bug report also seems very relevant, but it's about the sony-laptop module??
https://bugzilla.kernel.org/show_bug.cgi?id=15303

I also found a ton of bug reports that basically describe the same issue, all with different hardware, wlan modules, so it's kind of confusing that many of them mention hardware/brand specific fixes..
Comment 8 wey-yi.w.guy 2011-03-13 11:33:50 UTC
(In reply to comment #7)
> I've been fighting with an issue that seems very similar. On an Acer Aspire
> 4520 with an Atheros AR5001 Wireless Network Adapter, kernel 2.6.37.3,
> sometimes rfkill seemed to get stuck in 'Hard blocked: yes'. Pressing the wlan
> switch (it's a soft toggle, not a physical slider) seemed to toggle only 'Soft
> blocked' and it was impossible to actually get the card running again.
> 
> I think I've now figured out what actually happens: when booting with an
> enabled wlan (= disabled rfkill), switching between blocked and unblocked
> states works without problems. When booting with wlan disabled (= rfkill
> enabled), toggling the wlan switch does NOT take effect immediately, but only
> after REBOOTING the computer. Un- and reloading ath5k does not help. This leads
> to very confusing situations where it sometimes works, sometimes it doesn't,
> and nobody knows how to reproduce the issue.
> 
> 
> Here's a walkthrough of the entire procedure, starting with a session that has
> wlan enabled and everything working.
> 
> Initial state:
> 0: phy0: Wireless LAN
>     Soft blocked: no
>     Hard blocked: no
> 
> After toggling wlan switch the first time:
> 0: phy0: Wireless LAN
>     Soft blocked: yes
>     Hard blocked: no
> 
> After toggling wlan switch the second time:
> 0: phy0: Wireless LAN
>     Soft blocked: no
>     Hard blocked: no
> 
> Note that wlan works at this point as expected. The first toggle disabled it,
> the second reenabled it.
> 
> What I will do now is toggle the switch one more time (which will disable the
> wlan) and reboot the computer.
> 
> After the reboot, wlan does NOT work. However, rfkill lists the following:
> 0: phy0: Wireless LAN
>     Soft blocked: no
>     Hard blocked: no
> ifconfig shows the interface as up. iwlist wlan0 scan returns with 'No scan
> results'. 
> 
> After pressing the wlan switch once:
> 0: phy0: Wireless LAN
>     Soft blocked: yes
>     Hard blocked: no
> 
> After pressing it a second time (notice the Hard block):
> 0: phy0: Wireless LAN
>     Soft blocked: no
>     Hard blocked: yes
> 
> A third time:
> 0: phy0: Wireless LAN
>     Soft blocked: yes
>     Hard blocked: yes
> 
> Subsequent presses only switch between the previous 2 states. The wlan doesn't
> work at any point during this. Trying to put wlan0 up with ifconfig returns
> 'SIOCSIFFLAGS: Operation not possible due to RF-kill'.
> 
> *However*, after rebooting, the wlan switch action takes effect. 
> This means that an even number of wlan toggles will result in a blocked (=
> nonworking) state, and an odd number of wlan toggles will result in an
> unblocked state.
> 
> I was able to reproduce this 100% of the time once I actually figured out what
> was going on.
> 
> If you need more info please let me know.
> 
> PS:
> This bug report also seems very relevant, but it's about the sony-laptop
> module??
> https://bugzilla.kernel.org/show_bug.cgi?id=15303
> 
> I also found a ton of bug reports that basically describe the same issue, all
> with different hardware, wlan modules, so it's kind of confusing that many of
> them mention hardware/brand specific fixes..



did you try the patch from comments #6

Thanks
Wey
Comment 9 jakob gruber 2011-03-13 12:25:49 UTC
(In reply to comment #8)
> 
> did you try the patch from comments #6
> 
> Thanks
> Wey

No, I was under the impression that it doesn't apply to me since I have an Atheros AR5001 Wireless Network Adapter. lsmod | grep iwl returns nothing.
Comment 10 wey-yi.w.guy 2011-03-13 13:18:39 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > 
> > did you try the patch from comments #6
> > 
> > Thanks
> > Wey
> 
> No, I was under the impression that it doesn't apply to me since I have an
> Atheros AR5001 Wireless Network Adapter. lsmod | grep iwl returns nothing.

my bad, I miss the important word "Atheros", because we have the similar problem and we fix it not long ago.

Thanks
Wey
Comment 11 jakob gruber 2011-03-13 14:17:37 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > 
> > > did you try the patch from comments #6
> > > 
> > > Thanks
> > > Wey
> > 
> > No, I was under the impression that it doesn't apply to me since I have an
> > Atheros AR5001 Wireless Network Adapter. lsmod | grep iwl returns nothing.
> 
> my bad, I miss the important word "Atheros", because we have the similar
> problem and we fix it not long ago.
> 
> Thanks
> Wey

So is this really an issue that needs to be fixed by each wlan driver and not by rfkill (or something else)? Because it feels a bit strange that this is getting fixed in individual wlan and/or laptop modules and not in some centralized place.

If yes, should I open a new bug for ath5k?
Comment 12 wey-yi.w.guy 2011-03-14 00:57:36 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > (In reply to comment #8)
> > > > 
> > > > did you try the patch from comments #6
> > > > 
> > > > Thanks
> > > > Wey
> > > 
> > > No, I was under the impression that it doesn't apply to me since I have an
> > > Atheros AR5001 Wireless Network Adapter. lsmod | grep iwl returns nothing.
> > 
> > my bad, I miss the important word "Atheros", because we have the similar
> > problem and we fix it not long ago.
> > 
> > Thanks
> > Wey
> 
> So is this really an issue that needs to be fixed by each wlan driver and not
> by rfkill (or something else)? Because it feels a bit strange that this is
> getting fixed in individual wlan and/or laptop modules and not in some
> centralized place.
> 
> If yes, should I open a new bug for ath5k?


yes, please

Thanks
Wey
Comment 13 Orion Poplawski 2011-03-14 14:22:44 UTC
My issue turned out to be a lan port override that disables the radio when plugged into a ethernet connection.  Sorry for the noise.

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