Bug 1336297 - Bluetooth mouse doesn't work after resume with kernel 4.5.4
Summary: Bluetooth mouse doesn't work after resume with kernel 4.5.4
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 24
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-16 06:55 UTC by Bojan Smojver
Modified: 2016-06-28 23:33 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-06-28 23:33:59 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Linux Kernel 118471 0 None None None 2016-05-19 05:56:58 UTC

Description Bojan Smojver 2016-05-16 06:55:08 UTC
Description of problem:
Upon resume, bluetooth mouse (in this case Logitech M337) does not connect any more. Only trackpad available on this ThinkPad T450s.

Version-Release number of selected component (if applicable):
kernel-4.5.4-200.fc23

How reproducible:
Always.

Steps to Reproduce:
1. Boot, use mouse.
2. Suspend/resume.
3. No mouse (bluetooth connection does not appear).

Actual results:
Mouse unavailable.

Expected results:
Works with 4.4.9-300.fc23.

Additional info:
Quick search suggests 2ff13894cfb877cb3d02d96a8402202f0a6f3efd as the start of "bad" commits related to Bluetooth problems. See: http://lkml.iu.edu/hypermail/linux/kernel/1602.2/02725.html. Not Fedora specific, so I'm guessing this would be affecting F-24 and rawhide too.

Comment 1 Dimitris 2016-05-16 16:58:54 UTC
Seeing the same with F23 on a Thinkpad X250.  Bluetooth (mouse but also PAN) worked flawlessly up to 4.4.9-300.  With 4.5.4-200, bluetooth mouse and PAN don't work on resume from suspend.

FWIW, I can restore BT with "systemctl restart bluetooth.service".

Comment 2 Bojan Smojver 2016-05-16 23:47:07 UTC
Possibly related, I also noticed problems with my XT1562 phone when BT connection is attempted to the laptop running 4.5.4 kernel. It (supposedtly) successfully pairs the device, but then disconnects.

Reverting to 4.4.9 kernel and pairing again makes everything normal. Just FYI.

Comment 3 Bojan Smojver 2016-05-17 01:41:12 UTC
(In reply to Bojan Smojver from comment #2)
> Possibly related, I also noticed problems with my XT1562 phone when BT
> connection is attempted to the laptop running 4.5.4 kernel. It (supposedtly)
> successfully pairs the device, but then disconnects.

Log has (for kernel 4.5.4):

May 14 10:23:43 <hostname> bluetoothd[927]: Access denied: Rejecting service auth (0000110d-0000-1000-8000-00805f9b34fb) for /org/bluez/hci0/dev_E0_98_61_D6_2A_E6: not HID

Comment 4 Bojan Smojver 2016-05-18 02:26:31 UTC
I see a whole lot of new firmwares for various Intel hardware has been pushed to testing. I'm guessing some of those updates may affect Bluetooth as well.

Anyone cares to venture a guess whether testing 4.5.4 with the new firmware would produce different results?

Comment 5 Bojan Smojver 2016-05-18 02:58:17 UTC
(In reply to Bojan Smojver from comment #4)
> I see a whole lot of new firmwares for various Intel hardware has been
> pushed to testing. I'm guessing some of those updates may affect Bluetooth
> as well.
> 
> Anyone cares to venture a guess whether testing 4.5.4 with the new firmware
> would produce different results?

Just tried that. No dice.

The restart of bluetooth.service does reconnect the mouse. And the phone can connect too.

Comment 6 Bojan Smojver 2016-05-18 04:19:16 UTC
Here are the error messages from the log when manual connection is attempted to the mouse (without restarting the service on resume):

May 18 14:11:49 <host> bluetoothd[13349]: Can't get HIDP connection info
May 18 14:11:49 <host> bluetoothd[13349]: connect error: Device or resource busy (16)

Comment 7 Bojan Smojver 2016-05-19 05:25:39 UTC
Is it possible that this is some kind of user space bug triggered by changes in the kernel? Given that a restart of bluetooth.service makes the whole thing work again, maybe that is where the bug is...

Comment 8 Dimitris 2016-05-27 17:07:38 UTC
By the way, suspend/resume is not required to reproduce this:

- Bluetooth mouse working.
- From GNOME settings, turn bluetooth off.
- Turn mouse's own hw switch off.
- GNOME settings, bluetooth on.
- Moush switch on.
- Move mouse, wait for quite a while, no pointer movement.
- systemctl restart bluetooth.service
- Mouse works again.

Comment 9 Dimitris 2016-05-27 17:10:30 UTC
See also: https://bugzilla.redhat.com/show_bug.cgi?id=988481#c45

Comment 10 Bojan Smojver 2016-05-29 03:12:07 UTC
Are we thinking this is a userspace bug?

Comment 11 Bojan Smojver 2016-05-30 02:16:30 UTC
(In reply to Bojan Smojver from comment #10)
> Are we thinking this is a userspace bug?

bluez 5.40 is out, so maybe we should try that?

Comment 12 Bojan Smojver 2016-05-30 02:23:40 UTC
Assigning to bluez component until 5.40 gets built. Maybe that's the key to solving this problem.

Comment 13 Dimitris 2016-05-30 21:17:40 UTC
5.40 changelog has a couple of interesting-looking items:

ver 5.40:
        Fix issue with not storing GATT attributes.
        Fix issue with optional GATT notifications.
        Fix issue with reading GATT extended properties.
        Fix issue with GATT device name properties.
        Fix issue with previously paired devices.
        Fix issue with handling device removal.
        Fix issue with profile connection handling.
        Add support for TTY monitor protocol.

Comment 14 Bojan Smojver 2016-06-13 23:16:42 UTC
Assigning back to kernel and moving to F24, where this problem still exists, despite bluez 5.40.

Comment 15 David Ward 2016-06-26 10:19:33 UTC
@Bojan, from your comment on kernel-4.6.3-300.fc24: https://bodhi.fedoraproject.org/updates/kernel-4.6.3-300.fc24#comment-451180

Is this perhaps a duplicate of bug 1338025?

Comment 16 Bojan Smojver 2016-06-26 11:42:16 UTC
(In reply to David Ward from comment #15)
> @Bojan, from your comment on kernel-4.6.3-300.fc24:
> https://bodhi.fedoraproject.org/updates/kernel-4.6.3-300.fc24#comment-451180
> 
> Is this perhaps a duplicate of bug 1338025?

That other bug seems to be about wireless and Atheos chipset. This is about Bluetooth with Intel. So, probably different...

Comment 17 David Ward 2016-06-26 12:36:56 UTC
The other bug is about rfkill on HP laptops affecting wifi, Bluetooth, etc.

Comment 18 Bojan Smojver 2016-06-26 13:15:46 UTC
(In reply to David Ward from comment #17)
> The other bug is about rfkill on HP laptops affecting wifi, Bluetooth, etc.

OK. I have a Lenovo laptop (ThinkPad T450s) and this bug occurs with 4.5 kernel even if I just turn my mouse off and back on. So, maybe. No idea.

Anyhow, I was able to resume the second time and get the mouse back without restarting bluetooth service. So, maybe it did get fixed in 4.6.3 that just hit F24.

Comment 19 David Ward 2016-06-26 13:31:38 UTC
(In reply to Bojan Smojver from comment #18)
> (In reply to David Ward from comment #17)
> > The other bug is about rfkill on HP laptops affecting wifi, Bluetooth, etc.
> 
> OK. I have a Lenovo laptop (ThinkPad T450s)

Ok, please ignore me...I read "ThinkPad" and thought "ElitePad" (HP). Sorry for the noise.

Comment 20 Bojan Smojver 2016-06-28 23:33:59 UTC
This has been fixed in kernel-4.6.3-300.fc24.x86_64. I resumed many, many times now and the mouse consistently cames back online.


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