[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <922DC347-921E-4B82-9843-7758BD096854@holtmann.org>
Date: Wed, 2 Apr 2014 15:39:25 -0700
From: Marcel Holtmann <marcel@...tmann.org>
To: Thomas Bächler <thomas@...hlinux.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)
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@...el.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists