Bug 14545

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.

>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)

re-assign to henrique.

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.

Created attachment 24347 [details]
acpidump output

Created attachment 24348 [details]
dmidecode.txt.bz2

Created attachment 24349 [details]
dmesg-resume-bluetooth.txt.bz2

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.

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.

Created attachment 24421 [details]
dmesg-resume-bluetooth-newacpi-module.txt.bz2

Created attachment 24422 [details]
dmesg-resume-bluetooth-newacpi-nomodule.txt.bz2

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.

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" ?

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.

Henrique, any update on this bug?

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.

Created attachment 24961 [details]
Call the firmware properly so that it won't disable radios on resume

Please test whether the attached patch helps.

Tried the patch, sadly still doesn't work.

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.

Henrique, any updates on this bug?

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!

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!

Hanno,
please try the patch in comment #22.

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.

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...

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.

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.

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.

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.