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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 2 Apr 2014 15:39:25 -0700
From:	Marcel Holtmann <>
To:	Thomas Bächler <>
Cc:	"Gustavo F. Padovan" <>,
	Johan Hedberg <>,
	BlueZ development <>,
	"Linux-Kernel@...r. Kernel. Org" <>
Subject: Re: USB autosuspend causing trouble on Intel bluetooth (Linux 3.14)

Hi Thomas,

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



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists