Bug 199363 - Bluetooth mouse/keyboard stop working every ~ 5 minutes with no error or disconnect
Summary: Bluetooth mouse/keyboard stop working every ~ 5 minutes with no error or disc...
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Bluetooth (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: linux-bluetooth@vger.kernel.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-11 23:54 UTC by kernel
Modified: 2018-05-30 06:37 UTC (History)
2 users (show)

See Also:
Kernel Version: 4.16
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments

Description kernel 2018-04-11 23:54:27 UTC
On a machine with a Bluetooth mouse (Logitech T630) and Bluetooth keyboard (Logitech K810) connected to a USB BT adapter, after varying amounts of time, around 5-10 minutes, both devices will simultaneously stop working (keypresses, mouse moves etc. don't register).

Both devices still show as connected on the host; the keyboard also seems to think it's still connected at least, from it's indicators (the mouse doesn't have any way of showing its connectivity state).

Nothing shows up in dmesg at the point of loss of events.

Disconnecting the BT dongle and replugging it after ~2 seconds results in the devices successfully reconnecting. Very fast replugs (< 1 second) almost always fail to result in successful reconnection.

Two different dongles with different chipsets (one CSR 8510 A10, one BCM20702A0), both exhibit the same behaviour.

Reverting to a 4.15.x kernel (4.15.4) results in the problem disappearing so seems to definitely be a 4.16 regression (all previous kernel versions used also worked fine).
Comment 1 bugzilla 2018-05-08 22:54:21 UTC
Experiencing exact same symptoms Intel 7265, bluez 5.49, Microsoft BT Mouse.

Can reset from locked state by restarting bluetooth daemon (via systemd).

Problem is still there as of 4.16.7.  I am running Arch.

Reverting kernel back to 4.15.15 makes the lockup issue go away.
Comment 2 kernel 2018-05-13 11:04:13 UTC
In my case it looks like a regression relating to an active USB extension (maybe handling of USB data errors?) - plugging the USB Bluetooth adapter in directly results in stable operation.
Comment 3 bugzilla 2018-05-29 11:42:56 UTC
Appears resolved here with 4.16.11 kernel.  No bluetooth mouse lockups for 3 days.  (Knock on wood)
Comment 4 kernel 2018-05-30 06:37:56 UTC
Still seeing this in my case. 2 different instances of the same model of active USB extension still result in loss of input data after a while, on 4.16.11.

With a direct connection this doesn't happen.

Note You need to log in before you can comment on or make changes to this bug.