Red Hat Bugzilla – Bug 528744
Patch for btusb (linux-2.6-bluetooth-autosuspend.diff) breaks my bluetooth mouse
Last modified: 2013-01-10 02:17:17 EST
Description of problem:
The patch linux-2.6-bluetooth-autosuspend.diff (which is used in the current rawhide kernel 22.214.171.124-67.fc12.i686) breaks my bluetooth mouse.
With this patch the mouse gets discovered in the GNOME Bluetooth preferences, I can even pair successfully with it and it seems to be working at first. But the cursor movement stops every 2 seconds or so for about 0.5 seconds, which is rather annoying. Moreover, after about 20 - 30 seconds the mouse stops responding at all and this can be seen in dmesg:
usb 5-1: reset full speed USB device using uhci_hcd and address 4
btusb 5-1:1.0: no reset_resume for driver btusb?
btusb 5-1:1.1: no reset_resume for driver btusb?
All attempts to make the mouse (or any other bluetooth communication) to work again fail. I have tried "hciconfig hci0 reset" (also down/reset/up), turning the dongle off and on via a hardware kill switch (it is an integrated USB bluetooth adapter inside Lenovo ThinkPad T60), rmmoding and insmoding the btusb module. Only rebooting the machine helps, but the mouse works again for just a limited time.
After recompiling 126.96.36.199-67.fc12.i686 with the linux-2.6-bluetooth-autosuspend.diff patch removed (I didn't touch anything else) everything works perfectly again. The mouse cursor is moving smoothly and the mouse has been working for 2 hours now without any troubles. The mouse also worked in Fedora 10 and 11 without any problems.
Version-Release number of selected component (if applicable):
Always, if the kernel is compiled with linux-2.6-bluetooth-autosuspend.diff.
Steps to Reproduce:
Just use the bluetooth mouse in the usual way in GNOME (discover, connect, use).
Mouse cursor movements are not smooth and the bluetooth communication dies unexpectedly.
The bluetooth mouse should work flawlessly as in previous Fedora releases.
Bus 005 Device 002: ID 0a5c:2110 Broadcom Corp. Bluetooth Controller
(integrated inside Lenovo ThinkPad 60 with a kill switch, see http://www.thinkwiki.org/wiki/ThinkPad_Bluetooth_with_Enhanced_Data_Rate_%28BDC-2%29)
Microsoft Bluetooth Notebook Mouse 5000
generic-bluetooth 0005:045E:0700.0001: input,hidraw0: BLUETOOTH HID v1.00 Mouse
Updated the autosuspend patch to the latest upstream version in kernel-188.8.131.52-87.fc12. That may or may not fix the problems.
*** Bug 516756 has been marked as a duplicate of this bug. ***
I have been testing kernel-184.108.40.206-88.fc12 for several hours now and everything works without any problems. I consider the bug fixed.
Working again for me with 220.127.116.11-96.fc12
This also seems to have fixed the problem for me as well... thank you!
Updated patch fixes the problem by disabling autosuspend by default, which kind of defeats the object. Could those of you who had it broken before please provide the output of lsusb -v when run as root?
Created attachment 366139 [details]
Dell mini9 with internal Bluetooth and a Microsoft Intellimouse bluetooth mouse.
And with previous kernels, it's broken in the way described above?
Yes, fine with 2.6.29.x and 2.6.30.x in F11, broken in rawhide from 2.6.31-14 to 18.104.22.168-56, then 22.214.171.124-96 fixed it.
Created attachment 366248 [details]
lsusb -v output on Lenovo ThinkPad T60
(In reply to comment #6)
This is the output of lsusb -v on my machine (further hardware details in comment #0). Like I have written in comment #0, bt worked in Fedora 11 and the breakage was connected with the indicated patch. In the current kernel (126.96.36.199-96.fc12.i686.PAE) bt is working.
I understand the objective of autosuspend, but somehow I prefer a driver which works (but without autosuspend) than a driver which does not work (but with autosuspend) :)
I have not encountered any more problems with my bluetooth mouse since this bug was fixed. Therefore I suggest closing this report.
(In reply to comment #11)
> I have not encountered any more problems with my bluetooth mouse since this bug
> was fixed. Therefore I suggest closing this report.
The way I read it, the bug has only been "fixed" by disabling the autosuspend code, so should it really be re-opened pending a proper fix of the code?
(In reply to comment #12)
Like I have already written in comment #10, the basic functionality of the bluetooth mouse and the possibility to make use of autosuspend are probably two more-or-less separate issues.
This bug was about the basic functionality and I believe that it would be wiser to create a separate bug report concerning the autosuspend issue, rather than transforming this report. But that's just my humble opinion, so please feel free to reopen this bug if you really think that it is the best way to track the progress of making the autosuspend feature work flawlessly.