Bug 12219 - rfkill gets stuck at value "2"
Summary: rfkill gets stuck at value "2"
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_network-wireless@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-14 05:14 UTC by Khashayar Naderehvandi
Modified: 2009-05-11 15:53 UTC (History)
6 users (show)

See Also:
Kernel Version: 2.6.28rc
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Khashayar Naderehvandi 2008-12-14 05:14:59 UTC
Distribution: 
- Ubuntu Intrepid

Hardware Environment:
- Asus N20A, using the iwlagn driver on an Intel 5100

Software Environment:
- Ubuntu Intrepid. I've tried this with their stock 2.6.28 kernel, as well as build of my own of 2.6.28rc8.
- hal 0.5.12
- NetworkManager 0.7

Problem Description:
I filed this bug against HAL first, but it was resolved as NOTOURBUG there, so I'm trying to file it here instead. 

This laptop has a hardware switch that's supposed to disable the radio adaptors. Without NetworkManager running, it does this just fine. Switching to off, writes a 0 to /sys/class/net/wlan1/device/rfkill/rfkill0/state and 0 to
/sys/devices/platform/asus-laptop/bluetooth. Turning the switch back on, writes
1 to both of those files, and we're back up and rolling again.

However, when NetworkManager is running, the switch off will write 2 to
/sys/class/net/wlan1/device/rfkill/rfkill0/state, disabling the wifi.
Turning the switch back on, won't change this: the rfkill state will be stuck at 2, no matter what. Only thing to do to get wifi back is to modprobe -r iwlagn && modprobe -r rfkill && modprobe iwlagn.

The reason I first filed this against hal is that NetworkManager talks to hal, hal does the heavy lifting. Second, the problem wasn't there with hal 0.5.11 which, as far as I know, doesn't have a way to interfere directly with the rfkill interface. This feature is added in 0.5.12.

Steps to reproduce:
With hal 0.5.12, and NetworkManager running, first turn the hardware switch to off. Then turn it back on. Observe that /sys/class/net/wlan1/device/rfkill/rfkill0/state is stuck at 2.

---

http://dl.getdropbox.com/u/175461/lspci-nnvv.output
http://dl.getdropbox.com/u/175461/dmidecode.output

---

link to bug report against hal: https://bugs.freedesktop.org/show_bug.cgi?id=19040
Comment 1 John W. Linville 2008-12-15 05:25:50 UTC
Does ifconfig show the wlan0 device as "up"?
Comment 2 Khashayar Naderehvandi 2008-12-16 02:01:00 UTC
After switching off, and then back on, and confirming that /sys/class/net/wlan1/device/rfkill/rfkill0/state reads 2, ifconfig wlan1 gives:

wlan1     IEEE 802.11abgn  ESSID:"B2_private_BF"  
          Mode:Managed  Frequency:2.462 GHz  Access Point: Not-Associated   
          Tx-Power=15 dBm   
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B   
          Encryption key:off
          Power Management:off
          Link Quality:0  Signal level:0  Noise level:0
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0
Comment 3 Jonathan Dray 2008-12-22 16:31:42 UTC
Hi

I get the same problem with an ASUS M51VR laptop. But this time with wicd which may confirm that the problem is not related to networkmanager itself.

Distribution: 
- Debian lenny / SID

Hardware Environment:
- Asus M51VR, using the iwlagn driver on an Intel 5100

Software Environment:
- Debian 
- kernel : tested with 2.6.27.9 and 2.6.27.10
- hal 0.5.11.6
- wicd 1.5.6

Steps to reproduce:
With hal 0.5.11.6, and wicd running, first turn the hardware switch to
off. Then turn it back on. Observe that
/sys/class/net/wlan0/device/rfkill:rfkill0/state is stuck at 2.

I will try the modprobe trick till this issue is solved.
Please let me know if you need any additional information.

Regards,
Jonathan Dray
Comment 4 Jonathan Dray 2008-12-23 14:00:25 UTC
Hello,

I found the cause of the rfkill switch issue in my case.
The acpi driver loaded at boot time was not the right one.

The deprecated asus_acpi module that was loaded did not handle the wifi activation switch properly.
I had to blacklist it for the asus_laptop driver to be loaded instead.
(added the line "blacklist asus_acpi" in /etc/modprobe.d/blacklist)

After I rebooted the laptop the wifi card was up and running.
Now I have an issue with the iwlagn driver and wpa but that's another story.

I hope this information will help you in your invistigation.
good luck.

Regards,
Jonathan Dray
Comment 5 Khashayar Naderehvandi 2008-12-23 15:09:26 UTC
(In reply to comment #4)
Thank you for your comment. 

Just in case it's not clear, I've been using the asus-laptop module from the start, and still having this issue.
Comment 6 John W. Linville 2009-01-14 12:44:22 UTC
It seems like this could still be a problem with the asus-laptop driver?
Comment 7 Khashayar Naderehvandi 2009-01-14 16:00:16 UTC
(In reply to comment #6)
> It seems like this could still be a problem with the asus-laptop driver?
> 

With "still", do you mean 2.6.29-rc1? I haven't had a chance to try that kernel yet, but I haven't seen anything in the commit logs that looks related to this particular problem.
Comment 8 John W. Linville 2009-01-15 11:20:40 UTC
By "still" I mean "Despite the fact that you've been using the asus-laptop module from the start, the fact that Jonathan fixed a similar problem by switching from asus_acpi to asus-laptop still suggests that the problem Khashayar is experiencing could be related to asus-laptop rather than being a generic problem in the iwlagn driver."
Comment 9 Khashayar Naderehvandi 2009-01-15 12:11:05 UTC
I don't think the asus-laptop module (which is what I've been using all along), touches the rfkill interface. The only thing related to wlan under /sys/devices/platform/asus-laptop/ is the file 'wlan'. And the only thing that file controls is the wlan LED on the laptop. The old asus_acpi module probably tried to control the rfkill state, though. I could test things without the asus-laptop module loaded to remove all doubts, if that's desirable.
Comment 10 Alan 2009-03-26 13:00:36 UTC
please do
Comment 11 Johannes Berg 2009-04-04 08:21:00 UTC
If you're feeling adventurous, you could try my new rfkill code -- apply patches with rfkill in their name from http://johannes.sipsolutions.net/patches/kernel/all/LATEST/
Comment 12 Reinette Chatre 2009-05-08 21:44:37 UTC
No response from reporter. Is this bug still open?
Comment 13 Khashayar Naderehvandi 2009-05-10 08:05:49 UTC
I'm sorry for the lack of response. Non-computer related things have been taking up all of my time as of late. I haven't been able to follow up.

All I can say at this point is that the problem isn't around on my Ubuntu 9.04 install. I don't know what kind of workaround the Ubuntu folks have applied, but I haven't noticed this particular issue. So perhaps we could close this bug, and I'll re-open in case I realize I'm wrong?

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