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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <533C97A3.8080104@archlinux.org>
Date:	Thu, 03 Apr 2014 01:05:07 +0200
From:	Thomas Bächler <thomas@...hlinux.org>
To:	Marcel Holtmann <marcel@...tmann.org>
CC:	"Gustavo F. Padovan" <gustavo@...ovan.org>,
	Johan Hedberg <johan.hedberg@...il.com>,
	BlueZ development <linux-bluetooth@...r.kernel.org>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: Re: USB autosuspend causing trouble on Intel bluetooth (Linux 3.14)

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.



Download attachment "signature.asc" of type "application/pgp-signature" (902 bytes)