FS#68346 - [linux] bluetooth device drops after sleep or reboot

Attached to Project: Arch Linux
Opened by Pablo Klein-Bernard (asterion) - Tuesday, 20 October 2020, 06:28 GMT
Last edited by Andreas Radke (AndyRTR) - Wednesday, 27 January 2021, 15:47 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To No-one
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 9
Private No

Details

Description:
After resuming from sleep, rebooting, or restarting the bluetooth service, my bluetooth trackball loses its connection and I have to re-pair it using bluetoothctl and pressing the "pairing" button n the trackball for about 5 seconds. By downgrading the kernel from 5.9.1 to 5.8.14, the trackball now stays connected after sleep, reboot or restart.

My hardware is:
-- Lenovo Thinkpad P1 (20MDCTO1WW)
-- Wifi card: Intel Corporation Wireless-AC 9560 [Jefferson Peak] (rev 10)
-- Bluetooth Trackball: Logitech MX-Ergo

Steps to reproduce:
-- With linux-5.9.1.arch1-1-1-x86_64
-- with the Logitech MX-Ergo previously paired with bluetoothctl.
-- poweroff and back on or reboot or sleep and resume (or also # systemctl restart bluetooth)
   journal.txt (259.9 KiB)
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Wednesday, 27 January 2021, 15:47 GMT
Reason for closing:  Fixed
Additional comments about closing:  5.9.9.arch1-1
Comment by eta (eeeeeta) - Thursday, 22 October 2020, 11:24 GMT
I have the exact same problem with my HHKB Professional Hybrid bluetooth keyboard; downgrading the kernel also solved it for me.
I'm using a `Bus 004 Device 002: ID 8087:0025 Intel Corp. Wireless-AC 9260 Bluetooth Adapter` -- maybe the issue is in the Intel bluetooth drivers?
Comment by Sönke (eknoes) - Wednesday, 28 October 2020, 08:49 GMT
I have the same problem with my Thinkpad T495, (Intel Wireless-AC 9260). Only downgrading the kernel solves the problem.

My bluetooth devices that are affected: Logitech MX-Vertical and Logitech Ergo K860.

In the upstream bugtracker is already a similar bug: https://bugzilla.kernel.org/show_bug.cgi?id=209745
Comment by Pedro H. Lara Campos (PedroHLC) - Wednesday, 28 October 2020, 13:02 GMT
According to chaotic-aur's linux-tkg users, this patch seems to have solved for them:

https://lore.kernel.org/linux-bluetooth/20201022082304.31757-1-sathish.narasimman%40intel.com/
Comment by siphr (siphr) - Saturday, 31 October 2020, 12:01 GMT
Ok, I've have been trying to investigate the same problem with my mx ergo for a while now, its only today that I found this reported bug. My investigation led me to a particular issue and that is that my particular device does not have a "public" mac address it has a "random" one. Each time I restart or turn on/off the device, mac address changes. Bluez apparently, cannot reconnect to the "old" mac address as it no longer exists. I do not know how it used to work before, but this is what I've found out so far.
Comment by siphr (siphr) - Saturday, 31 October 2020, 12:57 GMT
I was going to apply the patch when I decided to Syu first. I can confirm that an upgrade to 5.9.2, fixes this broken behaviour for me. Can others confirm please so that we can close this ticket off?
Comment by Pablo Klein-Bernard (asterion) - Saturday, 31 October 2020, 17:50 GMT
Nope!!!! I updated to 5.9.2, and no trackball after restart, had to register it again with bluetoothtctl, and the issue happened again: no trackball after sleep resume. Went back to 5.8.14 and it worked again right away, without having to sign up the trackball (see my system details in the original report).
Comment by eta (eeeeeta) - Saturday, 31 October 2020, 17:51 GMT
Can confirm issue still persists with me on kernel 5.9.2.
Comment by Pablo Klein-Bernard (asterion) - Saturday, 31 October 2020, 17:55 GMT
I didn't try the patch; as I understand this would imply building the whole patched kernel before installing it. I prefer to wait for an update that works! By the ways there's no way I can run linux-lts on my system: it breaks my keyboard when I try to enter the password to access my fully luks encrypted drive. I guess I would need to downgrade everything on my laptop to 5.4-something for the current linux-lts to run properly.
Comment by siphr (siphr) - Saturday, 31 October 2020, 19:58 GMT
Scratch that, seemed to work after a reboot, could just be a coincidence, but definitely does not work after suspension.
Comment by Pablo Klein-Bernard (asterion) - Sunday, 15 November 2020, 20:00 GMT
By the ways, I just tried linux-5.9.8 and this issue was still unresolved.
Comment by siphr (siphr) - Sunday, 15 November 2020, 20:35 GMT
Hey Pablo, is that with or without the patch? I thought the patch would've been approved by 5.9.8 for mainline?
Comment by loqs (loqs) - Sunday, 15 November 2020, 22:10 GMT
@siphr the patch was added to bluetooth-next on 2020-11-09 which will be merged for 5.11, once it is in mainline it can be queued for stable.
It might be merged into mainline sooner as part of a fixes pull request.
Comment by Pablo Klein-Bernard (asterion) - Monday, 16 November 2020, 00:33 GMT
Ris, loqs : I confirm that I tried 5.9.8 without any patches. Thank you for following up.
Comment by loqs (loqs) - Wednesday, 18 November 2020, 22:28 GMT
Please try linux 5.9.9.arch1-1 currently in testing that contains [1]

[1] https://git.archlinux.org/linux.git/commit/?h=v5.9.9-arch1&id=b2e41088d2a2b3dd99f268833d8079d1a98ee3ea
Comment by Pablo Klein-Bernard (asterion) - Sunday, 22 November 2020, 17:04 GMT
I confirm that this issue is now fixed with linux 5.9.9.arch1-1. Thank you for taking care of this.
Comment by eta (eeeeeta) - Sunday, 22 November 2020, 17:30 GMT
Can confirm, issue is fixed for me as well.
Comment by siphr (siphr) - Sunday, 22 November 2020, 17:42 GMT
Seconded! Thanks.
Comment by siphr (siphr) - Sunday, 22 November 2020, 19:03 GMT
Seconded! Thanks.

Loading...