USB autosuspend causing trouble on Intel bluetooth (Linux 3.14)
I am having trouble due to the following commit, which landed in 3.14:
commit d2bee8fb6e18f6116aada39851918473761f7ab1
Author: Tedd Ho-Jeong An <[email protected]> Date: Tue Nov 12 13:16:41 2013 -0800
Bluetooth: Enable autosuspend for Intel Bluetooth device
I have an Intel bluetooth dongle (8087:07dc) built into a Thinkpad. I primarily use it with my bluetooth mouse. Whenever I stop using the mouse for a few seconds, the mouse stops working. When I turn it off, the bluetooth applet on my desktop shows it as connected indefinitely. I can fix this situation by either of these actions:
* restart bluetooth.service
* disable+reenable bluetooth in the bluetooth applet
* modprobe -r btusb && modprobe btusb
The mouse then works again until I stop moving it for a short while.
The culprit is USB autosuspend. When I explicitly disable it (echo 'on'
Quoted 1 line
power/control), the mouse works fine again. However, due to the
aforementioned commit, I need to do this manually after every boot and every resume, because btusb keeps setting it back to 'auto'. I have found no way of overriding this behaviour.
Any advice or help is appreciated.
Regards
Thomas Bächler
Marcel Holtmann
maintainerHi Thomas,
Quoted 18 lines
I am having trouble due to the following commit, which landed in 3.14:
commit
d2bee8fb6e18f6116aada39851918473761f7ab1Author: Tedd Ho-Jeong An <[email protected]> Date: Tue Nov 12 13:16:41 2013 -0800Bluetooth: Enable autosuspend for Intel Bluetooth device
I have an Intel bluetooth dongle (8087:07dc) built into a Thinkpad. I primarily use it with my bluetooth mouse. Whenever I stop using the mouse for a few seconds, the mouse stops working. When I turn it off, the bluetooth applet on my desktop shows it as connected indefinitely. I can fix this situation by either of these actions:
* restart bluetooth.service
* disable+reenable bluetooth in the bluetooth applet
* modprobe -r btusb && modprobe btusb
The mouse then works again until I stop moving it for a short while.
Quoted 5 lines
The culprit is USB autosuspend. When I explicitly disable it (echo 'on'
Quoted 1 line
power/control), the mouse works fine again. However, due to the
aforementioned commit, I need to do this manually after every boot and every resume, because btusb keeps setting it back to 'auto'. I have found no way of overriding this behaviour.
what USB controller do you have your Bluetooth controller attached to. I had the same issue, but it went away when some of the xHCI host controller fixes got merged. Some other reported issues with some USB 2 controllers.
You can easily check by running the "Inquiry (LIAC)” test from tools/hci-tester. Problem is that some of the HCI events are not making it to the host. They get delivered as soon as the device wakes up again. In this test case it is the Inquiry Complete event. If you poke the controller and send a new command, the even will be magically dequeued.
Regards
Marcel
Am 03.04.2014 00:39, schrieb Marcel Holtmann:
Quoted 9 lines
Hi Thomas,
Quoted 5 lines
The culprit is USB autosuspend. When I explicitly disable it (echo 'on'
Quoted 1 line
power/control), the mouse works fine again. However, due to the
aforementioned commit, I need to do this manually after every boot and every resume, because btusb keeps setting it back to 'auto'. I have found no way of overriding this behaviour.
what USB controller do you have your Bluetooth controller attached to. I had the same issue, but it went away when some of the xHCI host controller fixes got merged. Some other reported issues with some USB 2 controllers.
Thanks for replying to me here and on IRC. In order for nothing to get lost, I am reposting what I mentioned on IRC here.
$ lspci|grep USB 00:14.0 USB controller: Intel Corporation Lynx Point-LP USB xHCI HC (rev 04) 00:1d.0 USB controller: Intel Corporation Lynx Point-LP USB EHCI #1 (rev 04)
$ lsusb -t
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
|__ Port 5: Dev 3, If 0, Class=Chip/SmartCard, Driver=, 12M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/9p, 480M
|__ Port 6: Dev 2, If 0, Class=Vendor Specific Class, Driver=, 12M
|__ Port 7: Dev 5, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 7: Dev 5, If 1, Class=Wireless, Driver=btusb, 12M
|__ Port 8: Dev 4, If 0, Class=Video, Driver=uvcvideo, 480M
|__ Port 8: Dev 4, If 1, Class=Video, Driver=uvcvideo, 480MThis looks like it is attached to the xhci controller.
Output from bluemoon is as follows:
Bluemoon configuration utility ver 5.16
Controller Version Information
Hardware Platform: 55
Hardware Variant: iBT 2.0 (0x07)
Hardware Revision: 1.0
Firmware Variant: BT IP 4.0 (0x01)
Firmware Revision: 8.0
Firmware Build Number: 2-3.2013
Firmware Patch Number: 51
Quoted 1 line
You can easily check by running the "Inquiry (LIAC)” test from
tools/hci-tester. Problem is that some of the HCI events are not making it to the host. They get delivered as soon as the device wakes up again. In this test case it is the Inquiry Complete event. If you poke the controller and send a new command, the even will be magically dequeued.
I cannot figure out how to compile hci-tester. The Makefiles from bluez.git won't build it.
Hi Thomas,
Quoted 9 lines · Thomas Bächler
Quoted 6 lines
You can easily check by running the "Inquiry (LIAC)” test from
tools/hci-tester. Problem is that some of the HCI events are not making it to the host. They get delivered as soon as the device wakes up again. In this test case it is the Inquiry Complete event. If you poke the controller and send a new command, the even will be magically dequeued.I cannot figure out how to compile hci-tester. The Makefiles from bluez.git won't build it.
A quick look at Makefile.tools shows that you'll probably need to pass --enable-experimental to configure in order to build it.
Johan