Bug 14775
| Summary: | thinkpad-acpi: rfkill persistency across hibernate doesn't work | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Josip Rodin (joy+kernel) |
| Component: | Platform | Assignee: | Henrique de Moraes Holschuh (hmh) |
| Status: | CLOSED PATCH_ALREADY_AVAILABLE | ||
| Severity: | normal | CC: | hmh, lenb, rjw, rui.zhang |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.32 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 7216, 13615, 56331 | ||
| Attachments: | thinkpad-acpi: preserve rfkill state across suspend | ||
Known bug, although it might be less than straigthforward to fix. The first approximation to fix it is to kill a driver bug where it expects the rfkill core to reset its state (doesn't happen to persistent devices, bug introduced in 2.6.31). This *effectively* tells the firmware to do whatever it wants to the WWAN and bluetooth state, and the effect is unknown on UWB. Please test and report back what happens on STR and STD, reboot and shutdown, for all radios you happen to have (bluetooth, WWAN, UWB). I will attach the patch for convenience. Created attachment 24120 [details]
thinkpad-acpi: preserve rfkill state across suspend
Already submitted upstream (linux-acpi/acpi-test).
Yes, that's it, that definitely makes it not force it to off across suspend-to-disk. WWAN and Bluetooth lights just keep working as they did before, and Windows seems unaffected. No idea what's UWB...? I don't use suspend-to-RAM under Linux so I have no reference point for that. (I tried it now and it hosed my system so that's even worse, but probably irrelevant :) henrique, what's the status of this bug? can we close it? commit 208b996b6c460285650d39b2330f8ef82c007d10 Author: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Date: Wed Dec 9 01:36:22 2009 +0000 thinkpad-acpi: preserve rfkill state across suspend/resume shipped in 2.6.33-rc1 closed |
Hi, I have an integrated wireless setup inside my Lenovo Thinkpad T400 which normally works fine and provides WiFi, Bluetooth and WWAN connectivity. The wifi card is utilized by the iwlagn driver, and WWAN modem as well as Bluetooth appears separate devices, both managed by thinkpad_acpi. There's a single physical rfkill switch on the laptop. I upgraded from 2.6.28.10 to 2.6.30 and that went well as far as iwlagn was concerned, however, I started noticing that the WWAN device occasionally completely disappears. After some discussions with Henrique de Moraes Holschuh on ibm-acpi* lists, it became apparent that the driver does something to manage the state of the availability these two devices. This is visible from userspace via: /sys/devices/platform/thinkpad_acpi/wwan_enable /sys/devices/platform/thinkpad_acpi/rfkill/rfkill1/* and /sys/devices/platform/thinkpad_acpi/bluetooth_enable /sys/devices/platform/thinkpad_acpi/rfkill/rfkill0/* At first I couldn't pinpoint the exact state change that fails me, but since upgrading to 2.6.32 and re-testing, I've confirmed that a normal reboot restores the values to the setting of "enabled", whereas a hibernation sequence forces the values to "disabled". All the while BIOS setting remains intact - the device is enabled in it. That looks to be according to drivers/platform/x86/thinkpad_acpi.c terminology: TP_ACPI_WGSV_STATE_WWANEXIST = 0x0001, /* WWAN hw available */ TP_ACPI_WGSV_STATE_WWANPWR = 0x0002, /* WWAN radio enabled */ TP_ACPI_WGSV_STATE_WWANPWRRES = 0x0004, /* WWAN state at resume */ TP_ACPI_WGSV_STATE_WWANBIOSOFF = 0x0008, /* WWAN disabled in BIOS */ TP_ACPI_WGSV_STATE_BLTHEXIST = 0x0001, /* BLTH hw available */ TP_ACPI_WGSV_STATE_BLTHPWR = 0x0002, /* BLTH radio enabled */ TP_ACPI_WGSV_STATE_BLTHPWRRES = 0x0004, /* BLTH state at resume */ TP_ACPI_WGSV_STATE_BLTHBIOSOFF = 0x0008, /* BLTH disabled in BIOS */ After the resume from hibernation I'm getting the sysctl settings in state 0, which is what disables the hardware. This also has another annoying side-effect - I can't hibernate Linux and boot to Windows - there's nothing there that is able to enable the device again :) If you need more information, don't hesitate to let me know. Please fix it. TIA.