thinkpad T410: Bluetooth not getting disabled on suspend

Bug #698331 reported by Joel Ebel on 2011-01-06
42
This bug affects 5 people
Affects Status Importance Assigned to Milestone
pm-utils
Won't Fix
Medium
pm-utils (Ubuntu)
High
Martin Pitt
Lucid
Undecided
Martin Pitt
Natty
High
Martin Pitt

Bug Description

Binary package hint: pm-utils

I discovered this in Lucid, and verified the behavior still exists in natty.

/usr/lib/pm-utils/sleep.d/49bluetooth attempts to disable bluetooth using echo disable > /proc/acpi/ibm/bluetooth. Under normal operating conditions, this command seems to work, when run by hand:

# rfkill list
1: phy0: Wireless LAN
 Soft blocked: no
 Hard blocked: no
2: tpacpi_bluetooth_sw: Bluetooth
 Soft blocked: no
 Hard blocked: no
4: hci0: Bluetooth
 Soft blocked: no
 Hard blocked: no
# lsmod | grep ^btusb
btusb 18600 2
# echo disable > /proc/acpi/ibm/bluetooth
# rfkill list
1: phy0: Wireless LAN
 Soft blocked: no
 Hard blocked: no
2: tpacpi_bluetooth_sw: Bluetooth
 Soft blocked: yes
 Hard blocked: no
# lsmod | grep ^btusb
btusb 18600 0

Note that after disabling bluetooth in this manner, rfkill no longer even lists hci0, and the btusb usage count dropped from 2 to 0.

However, when this is called from /usr/lib/pm-utils/sleep.d/49bluetooth, during a suspend, this does not appear to be working. I patched 49bluetooth to look like this:

                rfkill list
                lsmod | grep ^btusb
                echo "Disabling Bluetooth"
                echo disable > /proc/acpi/ibm/bluetooth
                rfkill list
                lsmod | grep ^btusb

After suspending with this code in place, I get the following output in pm-suspend.log:

Running hook /usr/lib/pm-utils/sleep.d/49bluetooth suspend suspend:
1: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
2: tpacpi_bluetooth_sw: Bluetooth
        Soft blocked: no
        Hard blocked: no
6: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no
btusb 18600 2
Disabling Bluetooth
1: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
2: tpacpi_bluetooth_sw: Bluetooth
        Soft blocked: yes
        Hard blocked: no
6: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no
btusb 18600 2

Note that, while tpacpi_bluetooth_sw: Bluetooth is soft blocked, hci0 still exists and is not blocked. In addition, btusb still has a usage count of 2. For some reason, using /proc/acpi/ibm/bluetooth to disable bluetooth during suspend isn't working, and the module is still in use. I would like to try unloading btusb during suspend, using SUSPEND_MODULES, as I believe it may be causing suspend problems, but due to this inability to disable bluetooth during suspend, the module remains in use, and cannot be unloaded.

Tom Ellis (tellis) wrote :

Tested this on an x200 with bluetooth, I see the same behaviour, changing this one to confirmed.

Changed in pm-utils (Ubuntu):
status: New → Confirmed

Tom, just to be clear, you tested in maverick, right?

Tom Ellis (tellis) wrote :

Correct.

trellis@viper:~$ lsb_release -d
Description: Ubuntu 10.10
trellis@viper:~$ uname -a
Linux viper 2.6.35-24-generic #42-Ubuntu SMP Thu Dec 2 02:41:37 UTC 2010 x86_64 GNU/Linux

Changed in pm-utils (Ubuntu):
importance: Undecided → High
Martin Pitt (pitti) on 2011-01-30
Changed in pm-utils (Ubuntu Natty):
assignee: nobody → Martin Pitt (pitti)
status: Confirmed → In Progress
Changed in pm-utils (Ubuntu Lucid):
assignee: nobody → Martin Pitt (pitti)

(Original bug at https://launchpad.net/bugs/698331)

The 49bluetooth hook disables /proc/acpi/ibm/bluetooth but this isn't synchronous, i. e. it doesn't wait until the module usage count actually drops to 0. Due to that, it's impossible to add btusb to SUSPEND_MODULES (on some models/older kernels you need to do that to fix suspend problems), as at that point the module is still in use. To demonstrate that, I added some logging to the hook:

==== before: =====
--- /proc/acpi/ibm/bluetooth ----
status: enabled
commands: enable, disable
--- rfkill list ---
0: tpacpi_bluetooth_sw: Bluetooth
 Soft blocked: no
 Hard blocked: no
1: tpacpi_wwan_sw: Wireless WAN
 Soft blocked: no
 Hard blocked: no
2: phy0: Wireless LAN
 Soft blocked: no
 Hard blocked: no
10: hci0: Bluetooth
 Soft blocked: no
 Hard blocked: no
--- lsmod ---
btusb 18600 2

=== after writing /proc/acpi/ibm/bluetooth ====
--- /proc/acpi/ibm/bluetooth ----
status: disabled
commands: enable, disable
--- rfkill list ---
0: tpacpi_bluetooth_sw: Bluetooth
 Soft blocked: yes
 Hard blocked: no
1: tpacpi_wwan_sw: Wireless WAN
 Soft blocked: no
 Hard blocked: no
2: phy0: Wireless LAN
 Soft blocked: no
 Hard blocked: no
10: hci0: Bluetooth
 Soft blocked: no
 Hard blocked: no
--- lsmod ---
btusb 18600 2

As we can see, /proc/acpi/ibm/bluetooth got updated, but both rfkill as well as the module usage count are still active.

=== after sleep 0.5 ====
--- /proc/acpi/ibm/bluetooth ----
status: disabled
commands: enable, disable
--- rfkill ---
0: tpacpi_bluetooth_sw: Bluetooth
 Soft blocked: yes
 Hard blocked: no
1: tpacpi_wwan_sw: Wireless WAN
 Soft blocked: no
 Hard blocked: no
2: phy0: Wireless LAN
 Soft blocked: no
 Hard blocked: no
--- lsmod ---
btusb 18600 0

Now it disappeared from rfkill and the module usage count dropped to 0.

I'll write a better hook which waits for the module to get unused.

Created attachment 42750
patch against git head

What do you think about this?

Martin Pitt (pitti) wrote :

While I can't replicate the actual suspend problem on my X201 running current Natty, I confirm that the pm-utils hook doesn't immediately release the module, as writing to the file in /proc is not synchronous. Adding some debugging output to the hook reveals:

=== before ===-
--- /proc/acpi/ibm/bluetooth ----
status: enabled
commands: enable, disable
--- rfkill ---
0: tpacpi_bluetooth_sw: Bluetooth
 Soft blocked: no
 Hard blocked: no
1: tpacpi_wwan_sw: Wireless WAN
 Soft blocked: no
 Hard blocked: no
2: phy0: Wireless LAN
 Soft blocked: no
 Hard blocked: no
10: hci0: Bluetooth
 Soft blocked: no
 Hard blocked: no
--- lsmod ---
btusb 18600 2

=== after ===-
--- /proc/acpi/ibm/bluetooth ----
status: disabled
commands: enable, disable
--- rfkill ---
0: tpacpi_bluetooth_sw: Bluetooth
 Soft blocked: yes
 Hard blocked: no
1: tpacpi_wwan_sw: Wireless WAN
 Soft blocked: no
 Hard blocked: no
2: phy0: Wireless LAN
 Soft blocked: no
 Hard blocked: no
10: hci0: Bluetooth
 Soft blocked: no
 Hard blocked: no
--- lsmod ---
btusb 18600 2

=== after 0.5 s ===-
--- /proc/acpi/ibm/bluetooth ----
status: disabled
commands: enable, disable
--- rfkill ---
0: tpacpi_bluetooth_sw: Bluetooth
 Soft blocked: yes
 Hard blocked: no
1: tpacpi_wwan_sw: Wireless WAN
 Soft blocked: no
 Hard blocked: no
2: phy0: Wireless LAN
 Soft blocked: no
 Hard blocked: no
--- lsmod ---
btusb 18600 0

I. e. merely sleeping for 0.5 seconds after writing the proc file helps. I'll write a better hook which waits for the module to get unused.

Tom Ellis (tellis) wrote :

FYI, I couldn't reproduce the suspend issue, just the module not releasing the module immediately.

Changed in pm-utils:
status: Unknown → Confirmed
Martin Pitt (pitti) wrote :

I forwarded the bug upstream and wrote a patch (attached to upstream bug). If you are on lucid, you can test this by adding my SRU test PPA and upgrading (there is nothing else for lucid in this PPA, so it's safe to upgrade):

  https://launchpad.net/~pitti/+archive/sru-test

Add it with

  sudo add-apt-repository ppa:pitti/sru-test
  sudo apt-get update
  sudo apt-get upgrade

Thanks!

Hi Martin, and thanks for the prompt follow-up!

I asked the customer to test and report. I expect they will follow up in the public bug indeed.

It is very unfortunate that I cannot test myself, it would made progress much quicker. I'll ask to have a look at it, as he got the right hardware.

Joel Ebel (jbebel) wrote :

Thank you Martin. I've verified that your package does properly reduce the btusb usage count to 0, and it does allow for btusb to be unloaded using SUSPEND_MODULES. The actual suspend problem is intermittent, so time will tell if this resolves the suspend issue, with or without actually unloading the btusb module.

Some background on the suspend issues we've encountered with the new thinkpads (X201, T410(s)):
At some point in the Lucid lifecycle, suspend became unreliable, with the behavior that suspend wouldn't complete, leaving you back at the unlock screen. The error in pm-suspend.log was "/usr/lib/pm-utils/pm-functions: line 317: echo: write error: Device or resource busy". In kern.log, there were a couple errors that showed up. The most common one was "PM: Device 1-1.6 failed to suspend: error -110". Device 1-1.6 was the built in webcam. By adding uvcvideo to SUSPEND_MODULES, we resolved the majority of the suspend problems.

However, the other error that showed up on occasion was: "PM: Device usb1 failed to suspend: error -16" Device usb1 was the device that contained both the webcam and the bluetooth device. Since we were already removing the webcam, the bluetooth device seemed likely to be responsible. By manually disabling bluetooth before suspending, users have been able to reliably suspend, however, this isn't a good solution, as you must remember to do it. Due to this bug, adding btusb to SUSPEND_MODULES didn't work.

Now that we have a solution to this bug, I'll have the users that can reproduce this most often try the patch here by itself. If it doesn't resolve the problem on its own, I'll have them add btusb to SUSPEND_MODULES as well. I suspect that will resolve the problem completely. It's still puzzling that uvcvideo and possibly btusb are having problems suspending, but at least we have work-arounds available.

I haven't tried to reproduce the suspend problems in natty, but I was able to reproduce the module unloading problem reported in this bug.

Martin Pitt (pitti) wrote :

I committed the patch into the Debian pm-utils packaging git, will upload/sync soon.

Changed in pm-utils (Ubuntu Natty):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package pm-utils - 1.4.1-5

---------------
pm-utils (1.4.1-5) experimental; urgency=low

  * Add 13-49bluetooth-sync.patch: Wait for btusb module to get unused, so
    that you can remove it in SUSPEND_MODULES. (LP: #698331)
  * Add 14-disable-sata-alpm.patch: Disable SATA link power management by
    default, as it still causes disk errors and corruptions on many hardware.
    (LP: #539467)
 -- Martin Pitt <email address hidden> Tue, 01 Feb 2011 16:11:40 +0100

Changed in pm-utils (Ubuntu Natty):
status: Fix Committed → Fix Released
Changed in pm-utils:
importance: Unknown → Medium
Joel Ebel (jbebel) wrote :

Martin, what's the timeline for an SRU for Lucid? We've got a number of users who have confirmed this as a fix for their suspend problems on thinkpads. I'm wondering if we can expect a fix soon-ish, or should fork the package internally.

Martin Pitt (pitti) wrote :

Joel,

sorry seems we have been in a deadlock then: In the previous comment it sounded like you wanted to test this package locally first. I'll prepare a lucid-proposed package right away. However, lucid-updates is currently frozen until Feb 17 for the 10.04.2 release, so until then the fix needs to stay in lucid-proposed.

Accepted pm-utils into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in pm-utils (Ubuntu Lucid):
status: New → Fix Committed
tags: added: verification-needed
Joel Ebel (jbebel) wrote :

Ah. Sorry for the confusion. It's had enough testing to satisfy me. In addition, testing has shows that this fixes the btusb suspend problem entirely, without requiring adding it to SUSPEND_MODULES.

We still have uvcvideo in SUSPEND_MODULES, but I'm testing a newer version of that module, which seems to fix it without requiring unloading it.

Martin Pitt (pitti) wrote :

Joel, do you (or someone else at google) have the chance to test the package in lucid-proposed? Thanks in advance!

Joel Ebel (jbebel) wrote :

I've tested the proposed package and the updated 49bluetooth properly disables bluetooth before continuing. Thanks!

Martin Pitt (pitti) wrote :

Great! This can go into lucid-updates in two days, after the 10.04.2 release.

tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package pm-utils - 1.3.0-1ubuntu3

---------------
pm-utils (1.3.0-1ubuntu3) lucid-proposed; urgency=low

  * Add 13-49bluetooth-sync.patch: Wait for btusb module to get unused, so
    that you can remove it in SUSPEND_MODULES. (LP: #698331)
 -- Martin Pitt <email address hidden> Mon, 31 Jan 2011 15:34:52 +0100

Changed in pm-utils (Ubuntu Lucid):
status: Fix Committed → Fix Released

pm-utils hasn't been touched in eight years, none of this is likely to get addressed. Closing bugs and disabling the bz product.

Changed in pm-utils:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.