thinkpad T410: Bluetooth not getting disabled on suspend

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

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

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

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.

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

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.

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.

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

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

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.

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!

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.

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

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

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

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