Comment 9 for bug 698331

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.