Bug 14545

Summary: Bluetooth on Thinkpad always on after hibernation
Product: Drivers Reporter: Hanno Boeck (hanno)
Component: PlatformAssignee: Henrique de Moraes Holschuh (hmh)
Status: DEFERRED WILL_FIX_LATER    
Severity: normal CC: alan, rui.zhang, yakui.zhao
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.33 Subsystem:
Regression: No Bisected commit-id:
Bug Depends on:    
Bug Blocks: 56331    
Attachments: acpidump output
dmidecode.txt.bz2
dmesg-resume-bluetooth.txt.bz2
dmesg-resume-bluetooth-newacpi-module.txt.bz2
dmesg-resume-bluetooth-newacpi-nomodule.txt.bz2
Call the firmware properly so that it won't disable radios on resume
debugging patch: disable rfkill switch register with the rfkill core
Modular case with debug patch
Non-Modular case with debug patch

Description Hanno Boeck 2009-11-04 21:25:29 UTC
On my Lenovo Thinkpad T61, the bluetooth device is enabled and disabled by the thinkpad_acpi module.

On hibernation (no matter if I use tuxonice or in-kernel hibernation support) the bluetooth device/led is always enabled, no matter how it was before the hibernation.
Comment 1 ykzhao 2009-11-06 06:36:06 UTC
Will you please confirm whether the bluetooth device /led is always enabled on windows after  hibernation?
Will you please confirm whether the bluetooth can be disabled by thinkpad_acpi module after hibernation?
thanks.
Comment 2 Hanno Boeck 2009-11-06 10:09:14 UTC
>Will you please confirm whether the bluetooth device /led is always enabled on
>windows after  hibernation?
Sorry, windows-free laptop.

>Will you please confirm whether the bluetooth can be disabled by thinkpad_acpi
>module after hibernation?
Yes, the en/disable-feature works all the time, the only problem is it does not preserve it's state on hibernation. (btw, the wlan led does, if that matters anything)
Comment 3 Zhang Rui 2009-12-04 05:45:16 UTC
re-assign to henrique.
Comment 4 Henrique de Moraes Holschuh 2009-12-10 17:13:07 UTC
This is very weird.  The driver has a bug that forces all radios to DISABLED on 2.6.31 and 2.6.32, so I'd expect the inverse problem...

Please attach the usual information: dmidecode, acpidump, kernel version, and the full kernel log of a session where you: boot, turn bluetooth OFF, suspend and then resume.

Thanks.
Comment 5 Hanno Boeck 2009-12-29 14:43:34 UTC
Created attachment 24347 [details]
acpidump output
Comment 6 Hanno Boeck 2009-12-29 14:44:04 UTC
Created attachment 24348 [details]
dmidecode.txt.bz2
Comment 7 Hanno Boeck 2009-12-29 14:44:50 UTC
Created attachment 24349 [details]
dmesg-resume-bluetooth.txt.bz2
Comment 8 Henrique de Moraes Holschuh 2009-12-29 18:33:44 UTC
Did you try the fixed driver for the other resume problem?

You can find backports of the latest version of the driver in in http://sourceforge.net/projects/ibm-acpi/files/thinkpad-acpi/

Please run the driver with the "debug=0xffff" parameter, and do a suspend/resume cycle.

If you could use the newest version of the driver (see above), it logs more information and that might help figure out what is wrong.  Compile it with CONFIG_THINKPAD_ACPI_DEBUG=y in ".config" to get even more debug output.
Comment 9 Hanno Boeck 2010-01-03 17:38:43 UTC
I tried the latest patch and found something strange: When I compile the driver in the kernel, bug is as before, when I use it as a module, bug disappears.

I'm attaching module-output with debug (and without bug) and normal output, both with latest thinkpad-acpi-patch.
Comment 10 Hanno Boeck 2010-01-03 17:39:12 UTC
Created attachment 24421 [details]
dmesg-resume-bluetooth-newacpi-module.txt.bz2
Comment 11 Hanno Boeck 2010-01-03 17:39:32 UTC
Created attachment 24422 [details]
dmesg-resume-bluetooth-newacpi-nomodule.txt.bz2
Comment 12 Henrique de Moraes Holschuh 2010-01-05 00:49:03 UTC
You didn't tell me, is it keeping bluetooth state right across REBOOT and/or SHUTDOWN in the non-modular case?  That information will give me an important clue...

In the modular case, the bluetooth subsystem is loading before thinkpad-acpi, and it complicates the debugging of rfkill a lot as it also registers a fake rfkill switch just to be cute, and blocks thinkpad-acpi from setting the global bluetooth state from NVRAM.  I recommend that bluetooth be made modular and forced to load AFTER thinkpad-acpi in such cases.
Comment 13 Henrique de Moraes Holschuh 2010-01-05 00:52:24 UTC
Also, please test using /proc/acpi/ibm/bluetooth.  Does it report the correct state, or inverted state?  Does "echo enable > /proc/acpi/ibm/bluetooth" enable or disable bluetooth? What about "echo disable > /proc/acpi/ibm/bluetooth" ?
Comment 14 Hanno Boeck 2010-01-06 13:33:34 UTC
After reboot or shutdown, bluetooth is also always on (with non-modular thinkpad-acpi).

/proc/acpi/ibm/bluetooth always shows the correct state and en/disable always seems to work all the time.
Comment 15 Zhang Rui 2010-01-21 02:06:06 UTC
Henrique, any update on this bug?
Comment 16 Henrique de Moraes Holschuh 2010-01-21 02:38:34 UTC
No, I am completely stumped.  I did find a bug in how the firmware behaves, which I will have to work around, and that might even fix this issue, but it is not certain.
Comment 17 Henrique de Moraes Holschuh 2010-02-09 01:52:04 UTC
Created attachment 24961 [details]
Call the firmware properly so that it won't disable radios on resume

Please test whether the attached patch helps.
Comment 18 Hanno Boeck 2010-02-17 22:34:08 UTC
Tried the patch, sadly still doesn't work.
Comment 19 Henrique de Moraes Holschuh 2010-02-19 14:58:10 UTC
Hnrf, at this point, it is time to call in the big guns.

I will prepare a debug patch that cripples bluetooth rfkill support entirely. Then, we will know for sure whether the problem is in the firmware, thinkpad-acpi, or something else.
Comment 20 Zhang Rui 2010-03-10 03:15:30 UTC
Henrique, any updates on this bug?
Comment 21 Henrique de Moraes Holschuh 2010-03-10 18:12:15 UTC
Let me reorganize the information:

Module case:
  - kernel boots with firmware state: "bluetooth radio ON"
  - thinkpad-acpi module is reloaded
  - RFKILL wants the radio DISABLED, thinkpad-acpi complies and does so during init
  - Not much time later, RFKILL tells thinkpad-acpi to ENABLE bluetooth
  - Userspace tells thinkpad-acpi to DISABLE bluetooth through procfs
  - suspend & resume happens
  * thinkpad-acpi DOES NOT TOUCH the radio, so whatever happens, happens
    because of the firmware or because of the broken ACPI crap done during
    resume from disk.

Since the modular case is reported to not do anything idiotic, we know the firmware is tolerant of the stuff done on resume-from-disk.

static case:
  - kernel boots with firmware state: "bluetooth radio OFF"
  - nothing tries to enable or disable rfkill state
  - no further messages from thinkpad-acpi
  * thinkpad-acpi DOES NOT TOUCH the radio, so whatever happens, happens
    because of the firmware or because of the broken ACPI crap done during
    resume from disk.

So, the dmesg logs from the static case don't match comment #14 as far as I can tell, which means I don't have a clue on what is happening here other than "the firmware is playing with us".

It *is* worth noting that if the hardware rfkill switch is operated to radios off->radios on, the thinkpad IS LIKELY TO TURN BLUETOOTH RADIOS ON IN THE FIRMWARE.

Hanno, can you please redo the "not a module" testing WITHOUT the debug patch I will send in a few moments?

Please add the "thinkpad_acpi.debug=0xffff" parameter to the kernel command line in your bootloader, and please repost the boot + suspend + resume kernel log, describing to me *exactly* what operations (re. bluetooth and the rfkill switch) you did, which state bluetooth was in grub (i.e. before linux booted), which state bluetooth was BEFORE suspend, and which state bluetooth was AFTER resume.

Thanks!
Comment 22 Henrique de Moraes Holschuh 2010-03-10 18:14:03 UTC
Created attachment 25457 [details]
debugging patch: disable rfkill switch register with the rfkill core

Apply on top of patch 24961 (call the firmware properly so that it won't disable radios on resume).

Please test both cases (module and non-module) with the two patches applied.  Please give the kernel the "thinkpad_acpi.debug=0xffff" command line parameter for the non-modular case.


Thank you!
Comment 23 Zhang Rui 2010-03-25 06:22:24 UTC
Hanno,
please try the patch in comment #22.
Comment 24 Zhang Rui 2010-03-26 03:01:01 UTC
close the bug as this is no response from the bug reporter for more than a month.

Hanno,
please re-open it if you can test the patch and it doesn't work for you.
Comment 25 Henrique de Moraes Holschuh 2010-03-26 20:40:23 UTC
No, please keep it open.  I haven't proposed a FIX patch, let's see if someone else with the same problem will stumble upon this bug report, decide to test it and give me a report...
Comment 26 Hanno Boeck 2010-03-30 13:20:19 UTC
Sorry for my late reply, but I've been busy lately (but to Zhang Rui, two weeks is not a month).

Henrique, your patch actually changes the behaviour. If I apply attachment 25457 [details], bluetooth stays off after hibernate-resume. Attachment 24961 [details] is already applied to latest kernels as far as i can see.

I'll attach dmesg's.
Comment 27 Hanno Boeck 2010-03-30 13:27:19 UTC
Created attachment 25764 [details]
Modular case with debug patch

Kernel 2.6.33.1 + TuxOnIce 3.1 + debug-disable-tpacpi-rfkill.patch + thinkpad_acpi as a module

Boot option thinkpad_acpi.debug=0xffff

Boot, hibernate, resume. Bluetooth light is off all the time.
Comment 28 Hanno Boeck 2010-03-30 13:28:01 UTC
Created attachment 25765 [details]
Non-Modular case with debug patch

Kernel 2.6.33.1 + TuxOnIce 3.1 + debug-disable-tpacpi-rfkill.patch + thinkpad_acpi compiled in

Boot option thinkpad_acpi.debug=0xffff

Boot, hibernate, resume. Bluetooth light is off all the time.
Comment 29 Henrique de Moraes Holschuh 2012-06-23 15:39:43 UTC
Meh, I don't know what is happening.  Clearly, something thinkpad-acpi does when tuxonice is used is changing system state, but the driver is not actively messing with the radio state.  It is the firmware that is changing behaviour after the bluetooth nvram store methods are used at least once.

For now, I will have to chalk it up to some sort of firwmare bug, but please leave this open as I will return to it from time to time and review it to see if I get any ideas based on, e.g., experiences with newer firmware.