USB autosuspend causing trouble on Intel bluetooth (Linux 3.14)

USB autosuspend causing trouble on Intel bluetooth (Linux 3.14)

[Thomas Bächler]

[-- Attachment #1: Type: text/plain, Size: 1196 bytes --]

I am having trouble due to the following commit, which landed in 3.14:

commit d2bee8fb6e18f6116aada39851918473761f7ab1
Author: Tedd Ho-Jeong An <tedd.an@intel.com>
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'
> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: USB autosuspend causing trouble on Intel bluetooth (Linux 3.14)

[Marcel Holtmann]

Hi Thomas,

> I am having trouble due to the following commit, which landed in 3.14:
> 
> commit d2bee8fb6e18f6116aada39851918473761f7ab1
> Author: Tedd Ho-Jeong An <tedd.an@intel.com>
> 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'
>> 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

Re: USB autosuspend causing trouble on Intel bluetooth (Linux 3.14)

[Thomas Bächler]

[-- Attachment #1: Type: text/plain, Size: 2440 bytes --]

Am 03.04.2014 00:39, schrieb Marcel Holtmann:
> Hi Thomas,
> 
>> The culprit is USB autosuspend. When I explicitly disable it (echo 'on'
>>> 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, 480M

This 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

> 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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: USB autosuspend causing trouble on Intel bluetooth (Linux 3.14)

[Johan Hedberg]

Hi Thomas,

On Thu, Apr 03, 2014, Thomas Bächler wrote:
> > 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