thinkpad fn+f5: regression, rfkill toggling in the kernel instead of userspace

Thank you for taking the time to report this bug and help to improve Ubuntu.

In testing here, I find that shutting off acpid *completely* gives the same behavior. So this is not a flaw in acpi-support alone, because acpi-support isn't handling this event. Combined with bug #397698, this looks very much like a kernel issue.

elaborating a bit:

- the hotkey is still exposed to userspace, both via the thinkpad input device and as an acpi event. However, even shutting down gnome-settings-daemon and acpi-support, the hotkey still has the described effect - so something appears to be handling this in the kernel.
- as mentioned in bug #397698, I can't find a way to change the rfkill setting from userspace /anyway/.

I don't think this is specific to thinkpads. I am experiencing the same thing on my Asus N20A. Maybe the someone can change the description of this bug report?

On Sat, Jul 18, 2009 at 01:50:32PM -0000, Khashayar Naderehvandi wrote:
> I don't think this is specific to thinkpads. I am experiencing the same
> thing on my Asus N20A. Maybe the someone can change the description of
> this bug report?

Please provide more evidence of why you think you have the same bug on the
Asus. Different hardware should normally have separate bug reports, until
there's solid proof that they're the same bug.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Steve, sorry for not providing more details. Since I was seeing the exact same symptoms on my machine, I simply assumed I had the same bug. Particularly since the kernel part supposedly causing the issue is the platform independent rfkill module (as per LP #397698).

I'll try to give some more details here, and if you still think I have a different bug, let me know and I'll just go away.

In jaunty, the state of my bluetooth and wlan device, were controlled by means of /sys/devices/platform/asus-laptop/bluetooth, and /sys/class/net/wlan0/device/rfkill/*/state, respectively. In Karmic, they're both controlled by means of "/sys/class/rfkill/rfkill*/state".

Now, in Jaunty pressing Fn+F2 (which corresponds to Fn+F5 on the thinkpad) cycles the different possible states of bt+wlan. In Karmic, however, bt+wlan are turned off simultaneously. What's peculiar is that when FN+F2 toggles the radio devices to off, the /sys/class/rfkill/rfkillX that corresponds to the bluetooth device is removed (leaving me with just one rfkill device), and when it's toggled back on, the bluetooth-rfkill device comes back but, but this time named rfkillX+1 (that is rfkill1, becomes rfkill2, next time around rfkill3, etc.)

All this is being done with acpi-support stopped, which means (if I'm not misunderstanding anything here), that none of the platform specific scripts in /etc/acpi/* are run.

Likewise, I can't change the value of /sys/class/rfkill/rfkill*/state manually.

Shouldn't hal be in charge of hotkeys nowadays, instead of acpi-support? If I don't misremember this, hal doesn't know how to cycle states, but rather changes the state of bt+wlan the way described here.

Gah! I just wrote a long explanation for why I believe I'm experiencing the same bug, but the browser crashed.
So this is just a condensed version of that.

1) The problem seems to be related to rfkill, which is platform independent.
2) stopping acpi-support and acpid, I still have the same problem (i.e. the hotkey behaves the same as if they were running, which makes me think none of the platform specific scripts from /etc/acpi/* are run).
3) I can't change the values of /sys/class/rfkill/rfkill*/state manually.

Isn't hal responsible for hotkey handling nowadays? If I don't misremember, hal can't handle cycling of bt+wlan, but rather behaves just as explained here, turning bt+wlan either on or off simultaneously.

If you still think I'm having a different bug, let me know, and I'll go away.

Could someone please give us an update to this problem. Is this still occurring with the system fully upgraded?

Yes, this still happens with the current kernel. The kernel is intercepting Fn+F5 and toggling the power to the wireless antenna. This shouldn't happen, the event should be handled entirely in userspace.

(Confirmed that it's the kernel by stopping all of: acpid gnome-power-manager gnome-settings-daemon devkit-power-daemon)

Khashayar, yes, it does seem that this is a cross-platform bug from your description.

I just tried this on a T42p with kernel 2.6.31-9.29. Either this changed now or that model behaves different, which makes not much sense. I can see the event going through acpid and causing /etc/acpi/ibm-wireless being called.
So for me it goes through the 4 states. The only problem I see is that bluetooth now seems to be tied to two rfkill switches. One from the thinkpad-acpi driver which is persistent and one other from the hci driver which is created and removed whenever the ThinkPad driver changes state. Unfortunately it is always re-created in off state, so one has to enable it manually all the time.

I've reconfirmed this, shutting down all processes that could possibly be related:
 - gdm
 - NetworkManager
 - hal
 - acpid
 - devicekit-power
 - bluetoothd

And monitor the rfkill state from the console. When I hit Fn+F5, the wireless kill switch is still being toggled.
# cd /sys/class/rfkill/rfkill1/
# cat name
phy0
# cat type
wlan
# readlink device
../../phy0
# readlink device/device/driver
../../../../bus/pci/drivers/iwl3945
#

Is the T42p iwl3945 based?

No that has a ipw2200. I was mislead by the assumption that the wireless hotkey
only is connected to the ec which then has to relay that through acpi drivers.
But I learned that it also might be routed to the wireless device directly.

Could you gather the output of "rfkill list" during the sequence of 4 presses
of the wireless button (with acpid enabled)? This might show the various hard
and soft states better.

On Wed, Sep 09, 2009 at 02:17:29PM -0000, Stefan Bader wrote:
> No that has a ipw2200. I was mislead by the assumption that the wireless hotkey
> only is connected to the ec which then has to relay that through acpi drivers.
> But I learned that it also might be routed to the wireless device directly.

> Could you gather the output of "rfkill list" during the sequence of 4 presses
> of the wireless button (with acpid enabled)? This might show the various hard
> and soft states better.

Well, there are going to be fewer than 4 states being cycled through because
of bug #397698 (which I'm not trying to fix so long as the one system I have
to test with has broken rfkill handling in the kernel). Initial state, with
bluetooth manually disabled using 'rfkill block bluetooth':

$ rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
 Soft blocked: yes
 Hard blocked: no
1: phy0: Wireless LAN
 Soft blocked: no
 Hard blocked: no
$

press it once:

$ rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
 Soft blocked: no
 Hard blocked: no
1: phy0: Wireless LAN
 Soft blocked: yes
 Hard blocked: no
7: hci0: Bluetooth
 Soft blocked: yes
 Hard blocked: no
$

twice:

$ rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
 Soft blocked: yes
 Hard blocked: no
1: phy0: Wireless LAN
 Soft blocked: no
 Hard blocked: no
$

Similarly, if I manually unblock bluetooth first, it cycles between these
two states:

$ rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
 Soft blocked: yes
 Hard blocked: no
1: phy0: Wireless LAN
 Soft blocked: yes
 Hard blocked: no
$ rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
 Soft blocked: no
 Hard blocked: no
1: phy0: Wireless LAN
 Soft blocked: no
 Hard blocked: no
9: hci0: Bluetooth
 Soft blocked: no
 Hard blocked: no
$

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Hi!

Anything new on this? I can confirm the bug on my thinkpad r60e - Model 0657-4TG.

Best regards,
Acker

With 2.6.31-13, the kernel now /only/ toggles the software kill on the iwl3945, not on the bluetooth.

I think it's still wrong and a kernel bug for the kernel to be processing the hotkey in this fashion, but this at least makes it possible to work around the remaining issue in userspace with acpi-support if necessary.

The remaining issue has been worked around in the acpi-support scripts for karmic, so marking this 'wontfix' since there's no longer an urgent need for this to be changed (and doing so would require coordination with acpi-support again).

I think the kernel behavior is still a bug and that this should be fixed eventually.

Still experiencing this bug with Karmic 9.10 had to `rfkill enable` to get my wireless working.

Evan,

Since I'm not experiencing it anymore, you'll have to tell us what's different about your system. What wireless chip and bluetooth driver, what type of laptop, what kernel version, what is the output of acpi_listen when you press the wireless hotkey?

This bug report was marked as Triaged a while ago but has not had any updated comments for quite some time. Please let us know if this issue remains in the current Ubuntu release, http://www.ubuntu.com/getubuntu/download . If the issue remains, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

in lucid it works properly

It most certainly does not "work properly". The acpi-support package is still working around the fact that the kernel is toggling the antenna state instead of letting this be set by a userspace policy.

I must say it does not work properly in lucid (just updated from karmic): same behaviour as karmic.

Laptop model: asus f3e

acpi-support version: 0.136

daniele@asus:~$ uname -a
Linux asus 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:10:02 UTC 2010 i686 GNU/Linux

On a dell insperon 17 the Fn+F2 should turn wifi on/off - it does not.
Addtionally, dissabling bluetooth turns off Wifi and you cannot recover using the GUI.
This recipy get's wiFi back on, although I just borrowed it from other users with the same issue and have not figured out what it does.

sudo modprobe iwlagn power_level=5
sudo modprobe btusb reset=1
sudo rfkill unblock all

This is in 11.10 and 12.04 LTS beta 2 (I had hoped 12.04 fixed it)

Jeffrey Baker, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]