Fn F5 Does not Switch off Wifi in Gutsy - Thinkpad T40 Regression

Ok I did some investigating and on first boot, Fn+F5 works, after suspend and hibernate, it doesn't.

So I looked at (eventually) the ACPI values in /proc/acpi/ibm/hotkey

On first boot the value is set to: enable,0xffffff

After resuming from suspend or hibernation the value had been changed to 0xffff8f

If I then executed:

# echo enable,0xffffff >/proc/acpi/ibm/hotkey

It then worked again.

So I tracked down the 0xffff8f value to come from /etc/modprobe.d/thinkpad_acpi.modprobe which had the line:

options thinkpad_acpi hotkey=enable,0xffff8f experimental=1

I've changed this now to 0xffffff and it works now.

What would 0xffff8f mean? Why has this been done. Can anyone else say with a T40, T41, T42, T43 or other Tx series confirm that the symptoms described here are indeed the case and that whether this fixes it for them? If so, this might need to be put into a Gutsy bug fix?

Certainly did for me. Just need to figure out why sometimes wireless does not work sometimes after resuming from suspend/hibernate and that's all my Ubuntu T40 bugs squashed :)

Vicky

Hey,
Upgraded from Gutsy to Hardy on a T42. Still doesn't work. Never worked. Has to do with acpi and fn-f5 not working in any way. Too hard :)

Mich

Is this symptom still reproducible in 8.10?

I didn't think that this erroneous behavior was not normal. I therefore used Fn-F5 only to toggle bluetooth. When I upgraded to 8.10 today, I noticed this strange new behavior and found my way to this bug thinking that I found a new bug. I now add "echo disable > /proc/acpi/ibm/bluetooth" to /etc/rc.local because I don't need to have bluetooth on all the time.

I have a TP 41 with wireless and bluetooth. I installed 8.10. When I first boot up, FN + F5 does toggle both wireless and bluetooth. When I hibernate, then resume, the bluetooth comes back on, but not the wireless. I can thenn toggle bluetooth off an on but the wireless remains off until I reboot.

I suspect that Ubuntu believes my laptop is a Tooshiba? The modprobe.d output is below...

root@Ubuntu:/etc/modprobe.d# ls
aliases blacklist blacklist-watchdog libsane
alsa-base blacklist-framebuffer fuse lrm-video
arch blacklist-modem isapnp options
arch-aliases blacklist-oss libpisock9 toshiba_acpi.modprobe
root@Ubuntu:/etc/modprobe.d#
root@Ubuntu:/etc/modprobe.d# cat toshiba_acpi.modprobe
options toshiba_acpi hotkeys_over_acpi=1
root@Ubuntu:/etc/modprobe.d#

I tried the following on my TP41 on Ubuntu 8.10 and it has no affect.
# echo enable,0xffffff >/proc/acpi/ibm/hotkey

also, tried changing the following line in the misnamed??? toshiba_acpi.hotkeys
options toshiba_acpi hotkeys_over_acpi=1
-to-
options thinkpad_acpi hotkey=enable,0xffff8f experimental=1
then suspending and resuming but still no change.

If I could get this suspend/resume feature working, I'd have no other big problems left on my Thinkpad.

I may have been mistaken about Fn+F5 ever disabling wireless. Seems like it may have only toggled bluetooth, not wireless. I've been fighting 2 issues, 1st getting bluetooth to work, then getting wireless (802.11) driver iwl3945 adapter to turn on again after resuming from hibernation.

On Thinkwik found a solution for enabling wireless. It appears the ath_pci module was being removed on suspension. To prevent, add following file to prevent kernel module from unloading:
/etc/pm/confg.d/madwifi
SUSPEND_MODULES=ath_pci

No response from the original submitter to the inquiry about whether this is reproducible in Ubuntu 8.10, and there's been ongoing work on ThinkPad hotkey handling in successive releases, so I'm presuming the original problem is fixed.

David, the problem with the wireless not coming back after resume was a known kernel bug that has since been resolved. If you are still having problems with this or any other hotkeys on your ThinkPad, at this point it's likely a result of the various unrelated changes you've made to your configuration. You should remove the /etc/modprobe.d/toshiba_acpi.modprobe and /etc/pm/config.d/madwifi files and if the problem persists in Ubuntu 9.04 or later, file a new bug report.