Bug 2100761

Summary: Bluetooth peripherals don't reconnect after suspend/resume with kernel 5.18.5. With 5.17.14 it works fine.
Product: [Fedora] Fedora Reporter: Kamil Páral <kparal>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 36CC: acaringi, adscvr, airlied, alciregi, antoine+redhat, awilliam, bcotton, brian.reading, bskeggs, darwyn00, dimitris, fedora_45sg, hbarcomb, hdegoede, hpa, jarodwilson, jforbes, jglisse, jonathan, jorge.gonzalez, josef, kernel-maint, lgoncalv, linville, mail, marcel, masami256, mchehab, me, michele.mazza, ml, nmiell, pfpschneider, ptalbert, redhat.fu3l8, robatino, sbarcomb, simon, smoker.tabac, steved, woutersj
Target Milestone: ---Keywords: CommonBugs
Target Release: ---Flags: kparal: fedora_prioritized_bug?
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: https://ask.fedoraproject.org/t/common-issue/24076
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-08-22 16:32:53 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
dmesg none

Description Kamil Páral 2022-06-24 08:55:53 UTC
1. Please describe the problem:
When I boot kernel-5.18.5-200.fc36.x86_64 (or 5.18.6-200, the same issue), my bluetooth mouse (Logitech M720) no longer reconnects when I wake my laptop from suspend. It connects fine on fresh boot, but not on resume from suspend.

As a workaround, I have to open gnome-control-center -> Bluetooth. I can immediately close it, and after a few moments, my mouse starts working again. At that moment, this gets printed into system journal:

čen 24 10:36:31 hydra systemd[1480]: Started dbus-:1.2-org.gnome.Characters.
čen 24 10:36:31 hydra systemd[1480]: Started dbus-:1.2-org.gnome.Settings.SearchProvider.
čen 24 10:36:31 hydra gnome-character[3060]: JS LOG: Characters Application started
čen 24 10:36:31 hydra gnome-shell[1616]: Timelines with detached actors are not supported. <unnamed>[<Gjs_ui_search_ListSearchResult>:0x55f3ddaed760] in animation of duration 100ms but not on stage.
čen 24 10:36:31 hydra gnome-shell[1616]: Timelines with detached actors are not supported. <unnamed>[<Gjs_ui_search_ListSearchResult>:0x55f3ddae6f50] in animation of duration 100ms but not on stage.
čen 24 10:36:32 hydra systemd[1480]: Started app-glib-gnome\x2dbluetooth\x2dpanel-3109.scope - Application launched by gnome-control-center-search-provider.
čen 24 10:36:32 hydra systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
čen 24 10:36:32 hydra audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
čen 24 10:36:32 hydra gnome-control-c[3109]: BluetoothHardwareAirplaneMode: 0
čen 24 10:36:33 hydra kernel: input: M720 Triathlon Keyboard as /devices/virtual/misc/uhid/0005:046D:B015.0004/input/input21
čen 24 10:36:33 hydra kernel: input: M720 Triathlon Mouse as /devices/virtual/misc/uhid/0005:046D:B015.0004/input/input22
čen 24 10:36:33 hydra kernel: hid-generic 0005:046D:B015.0004: input,hidraw2: BLUETOOTH HID v0.07 Keyboard [M720 Triathlon] on 20:1e:88:1a:f6:70
čen 24 10:36:33 hydra systemd-logind[1112]: Watching system buttons on /dev/input/event17 (M720 Triathlon Keyboard)


If I boot the same system (no package version changed) with kernel-5.17.14-300.fc36.x86_64, everything works as expected - the mouse is reconnected automatically immediately after resume from suspend. Those "kernel: input: M720 Triathlon ..."  lines are printed into the journal immediately after resume, it is not necessary to poke it through gnome-control-center.


2. What is the Version-Release number of the kernel:

kernel-5.18.5-200.fc36.x86_64

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :

Works with: kernel-5.17.14-300.fc36.x86_64
Broken with: kernel-5.18.5-200.fc36.x86_64

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:

Yes, 100%.
1. Boot the system fresh, verify that the bluetooth mouse works out of the box.
2. Suspend the system (close the lid, etc).
3. Wait a few seconds.
4. Resume the system.
5. Try moving the mouse, the cursor doesn't move. Even if you wait a long time.
6. Open gnome-control-center -> Bluetooth. You can close it immediately.
7. See that the mouse gets reconnected quickly.

5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:

I haven't tested, I can try if you want.

6. Are you running any modules that not shipped with directly Fedora's kernel?:

No.

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

Attached. You can see that the mouse successfully connected on system boot at 10:35:57. The system gets suspended at 10:36:07 and resumed 10:36:19. The mouse reconnects at 10:36:33 when I manually start the gnome-control-center.

Comment 1 Kamil Páral 2022-06-24 08:56:29 UTC
Created attachment 1892409 [details]
dmesg

Comment 2 michele mazza 2022-07-03 23:52:18 UTC
Can confirm on Intel AX201 Bluetooth.
Log from `systemctl status bluetooth` says:
```
bluetoothd[32297]: Controller resume with wake event 0x0
bluetoothd[32297]: profiles/input/device.c:ioctl_is_connected() Can't get HIDP connection info
```

`systemctl restart bluetooth` fixes it.

Comment 3 Dimitris 2022-07-04 06:48:40 UTC
Reproduces with a Logitech MX Master 3 on a Framework laptop with:

Bus 003 Device 008: ID 8087:0032 Intel Corp. AX210 Bluetooth

I only see this message:

Jul 03 23:41:09 greebo bluetoothd[1649]: Controller resume with wake event 0x0

but not the:

profiles/input/device.c:ioctl_is_connected() Can't get HIDP connection info

one in my case.

Comment 4 Rainer Stransky 2022-07-08 08:03:09 UTC
Exactly the same problem on my ASUS UX425J as described by Kamil with my 
  input: RAPOO BT4.0 Mouse Consumer Control as /devices/virtual/misc/uhid/0005:000E:3412.0019/input/input69
only at resume.

Restarting bluetooth or open the Gnome Bluetooth settings window solves the problem. 

In the kernel buffer there is the following message:
 [85473.535251] Bluetooth: hci0: Cannot set wakeable for RPA

Comment 5 jorge.gonzalez 2022-07-08 14:33:01 UTC
Still happening with kernel-5.18.7-200.fc36.x86_64

Comment 6 jorge.gonzalez 2022-07-09 08:19:16 UTC
...after upgrading today, still happening also with kernel-5.18.10-200.fc36.x86_64

Comment 7 darwyn00 2022-07-10 09:35:29 UTC
Can confirm that the bluetooth resume failure occurs on kernel 5.18.6 for my Logitech K850 Keyboard and my Logitech M585 Mouse. Reverting to kernel 5.17.5-300 seems to work for me. I also versionlock'ed the packages to make sure it doesn't get uninstalled using the following cmds:

sudo su
dnf install kernel-5.17.5-300.fc36.x86_64 kernel-core-5.17.5-300.fc36.x86_64 kernel-modules-5.17.5-300.fc36.x86_64

dnf install 'dnf-command(versionlock)'
dnf versionlock add kernel-5.17.5-300.fc36.x86_64 kernel-core-5.17.5-300.fc36.x86_64 kernel-modules-5.17.5-300.fc36.x86_64

grubby --set-default /boot/vmlinuz-5.17.5-300.fc36.x86_64

reboot

Comment 8 Yuriy 2022-07-10 12:23:13 UTC
My suspend/resume problems started with kernel 5.17.x. The suspend was followed by a spontaneous resume. I can confirm that in 5.18.10 the spontaneous resume no longer occurs, but there is a new problem with the bluetooth resume error. I am using System76 Darter Pro 6 notebook and Microsoft Mobile Mouse 3600. I had to downgrade to kernel-5.16.20-200.fc35.x86_64 in which suspend/resume works fine for me.

Comment 9 Nicholas Miell 2022-07-11 21:39:55 UTC
Same problem on 5.18.5 with an Intel Corporation Wi-Fi 6 AX200 (rev 1a) DeviceName: RTL8111EPV Subsystem: Intel Corporation Wi-Fi 6 AX200NGW and every Bluetooth device I bothered to test (Logitech MX Ergo, Logitech K380 keyboard, 8BitDo SN30 Pro+).

On 5.18.7 the Bluetooth controller doesn't initialize at boot at all and I stopped testing any other 5.18 kernels.

Comment 10 Nicholas Miell 2022-07-20 07:30:08 UTC
Tested again with kernel-core-5.18.11-200.fc36.x86_64 and iwlax2xx-firmware-20220708-136.fc36.noarch, Bluetooth successfully initializes at boot but devices still do not reconnect without manual intervention after a suspend/resume cycle.

Comment 11 Brian Reading 2022-07-20 20:49:47 UTC
I can confirm this same bad behavior with Intel Corp. AX201 Bluetooth controller and 5.18.11-200.fc36.x86_64.

Comment 12 jorge.gonzalez 2022-07-25 21:13:17 UTC
Updated to kernel-5.18.13-200.fc36.x86_64, still happening.

Comment 13 David Patin 2022-07-27 07:10:40 UTC
I confirm this issue

Comment 14 Alper Kanat 2022-07-31 12:21:12 UTC
I confirm this issue on Fedora Silverblue with the latest and greatest updates.

$ cat /etc/os-release
NAME="Fedora Linux"
VERSION="36.20220730.0 (Silverblue)"
ID=fedora
VERSION_ID=36
VERSION_CODENAME=""
PLATFORM_ID="platform:f36"
PRETTY_NAME="Fedora Linux 36.20220730.0 (Silverblue)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:36"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora-silverblue/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=36
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=36
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
VARIANT="Silverblue"
VARIANT_ID=silverblue
OSTREE_VERSION='36.20220730.0'

$ uname -r
5.18.13-200.fc36.x86_64

Comment 15 Kamil Páral 2022-08-01 11:04:25 UTC
At this point, I don't think we need any more confirmations that this is broken.

An interesting information would be, however, whether this affects all systems and all devices, or not. In other words, if there's someone whose PC reconnects a Bluetooth mouse/keyboard just fine after suspend+resume (with kernel>=5.18.5). Or whether someone with an affected PC can find a Bluetooth mouse/keyboard which is NOT affected after suspend+resume (while a different BT mouse/keyboard IS affected, on the same system).

Also, if anyone finds a link to the upstream issue, that would be helpful.

Comment 16 Peter F. Patel-Schneider 2022-08-01 12:05:14 UTC
I'm not even sure how to report issues to the bluez team.   There is a website http://www.bluez.org/ but it doesn't say how to report bugs.  There is a mailing list (which is hard to find) with archive at https://www.spinics.net/lists/linux-bluetooth/ but it appears to be mostly patch messages.  Ubuntu has a page on how to report bluez bugs https://discourse.ubuntu.com/t/bluez-report-a-bug/19994 but that appears to be only for Ubuntu.

I don't understand why there isn't an obvious way to report bugs in such an important part of Linux.

If anyone knows the correct way to report a bluez bug, please speak up here.

Comment 17 Peter F. Patel-Schneider 2022-08-01 12:26:59 UTC
I had the same progression as Yuriy reports.  An update to 5.17 meant that my laptop did not suspend.  Some update to 5.18 fixed that problem but now Bluetooth devices no longer reliably connect after a suspend and resume.  It may also be that there have been recent changes.  At one time bluetooth was disabled after a suspend.  This does not appear to be happening now but my bluetooth devices do not connect.  I can sometimes make my Logitech MX Master 3 connect by moving it for four or five seconds but I always have to connect my Logitech Craft Keyboard through the applet.  I also have to connect to my LG HTS speaker system through the applet.

I have an IceLake laptop with the 8087:0026 Intel Corp. AX201 Bluetooth controller.

Comment 18 Jeroen Wouters 2022-08-01 13:25:26 UTC
These seem to be relevant bug reports:

https://bugzilla.kernel.org/show_bug.cgi?id=216314
https://github.com/bluez/bluez/issues/373

Comment 19 Artem S. Tashkinov 2022-08-01 14:47:15 UTC
(In reply to Jeroen Wouters from comment #18)

> These seem to be relevant bug reports

I hesitated to file a bug report upstream because I thought I was the only one affected. Looks like I'm not. Should have done it earlier.

People's best bet at the moment is performing regression testing using git bisect. I'm not ready to do it just yet.

Comment 20 Peter F. Patel-Schneider 2022-08-01 15:19:43 UTC
What should be bisected?  The kernel?  The Bluez utilities?  Systemd?  Without some indication of what is causing the problem it is hard for users to know how to help find a cause.  And, of course, without some indication from users as to what is going wrong it is hard for developers to find a potential cause.   And to further compound the problem there appear to have been at least two different fixes for what appear to be related problems.

Comment 21 Peter F. Patel-Schneider 2022-08-01 15:30:07 UTC
There is a very similar bug report from late last year https://github.com/bluez/bluez/issues/220 and https://github.com/bluez/bluez/issues/275

Comment 22 Artem S. Tashkinov 2022-08-01 16:04:26 UTC
(In reply to Peter F. Patel-Schneider from comment #20)
> What should be bisected?

The kernel as many have reported it's a kernel issue though I have to admit I'm far from sure who's the culprit.

(In reply to Peter F. Patel-Schneider from comment #21)
> There is a very similar bug report from late last year https://github.com/bluez/bluez/issues/220 and https://github.com/bluez/bluez/issues/275

Restarting bluetooth.service does nothing at least for me.

Comment 23 Artem S. Tashkinov 2022-08-01 23:09:03 UTC
A bluez developer has chimed in, https://github.com/bluez/bluez/issues/373#issuecomment-1201810770

> @birdie-github Looks like disable Scan during suspend but we don't re-enable it during resume:
> 
> < HCI Command: Write Scan Enable (0x03|0x001a) plen 1
> #9 [hci0] 12.425215
>         Scan enable: No Scans (0x00)
> > HCI Event: Command Complete (0x0e) plen 4
> #10 [hci0] 12.429189
>       Write Scan Enable (0x03|0x001a) ncmd 2
>         Status: Success (0x00)
> 
> Looks like the following shall have it fixed, but it probably need to be tagged for stable:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=68253f3cd715e819bc4bff2b0e6b21234e259d56

This is probably fixed in 5.19 but it would be nice if Fedora applied the patch to 5.18 because 5.19 will take a few weeks to be approved.

Comment 24 Artem S. Tashkinov 2022-08-01 23:53:56 UTC
I've applied the patch and it's made no difference for me unfortunately.

Comment 25 Artem S. Tashkinov 2022-08-02 00:55:51 UTC
OK, a full reboot has fixed the issue. No idea why a module reloading didn't.

Please apply the aforementioned patch to Fedora's 5.18.x kernel.

https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/patch/?id=68253f3cd715e819bc4bff2b0e6b21234e259d56

Comment 26 Artem S. Tashkinov 2022-08-04 19:33:03 UTC
Looks like no one on Fedora's kernel team is going to do anything, could you please at least close the bug report now that the patch is available?

I've pinged the three developers behind the patch and was told to submit it to stable myself, however I'm not doing that now or ever because I've had a horrible experience dealing with stable and Mr. Greg Kroah-Hartman in particular.

5.19 seemingly already includes the fix.

Comment 27 Kamil Páral 2022-08-05 07:36:58 UTC
@jforbes Could you please look into this? I don't know what the schedule for 5.19 in Fedora is, but it would be good to fix this for our users soon. This issue seems to affect everybody with Bluetooth.

> could you please at least close the bug report now that the patch is available?

This bug report is supposed to stay open until it's fixed in Fedora. Also, proposing as a blocker for F37, just in case.

Comment 28 Adam Williamson 2022-08-05 16:54:15 UTC
F37's already on kernel 5.19, so this probably doesn't need to be a blocker for F37...

Comment 29 Kamil Páral 2022-08-08 10:34:44 UTC
My fault. I'll check with kernel 5.19 (or anyone, feel free to beat me to it [1]), report the outcome and update the blocker field if necessary.

[1] https://koji.fedoraproject.org/koji/packageinfo?packageID=8

Comment 30 Kamil Páral 2022-08-11 08:51:40 UTC
I tested with kernel-5.19.0-300.fc37.x86_64 and I don't see any improvement. My bluetooth mouse still doesn't reconnect after resume, unless I open gnome-control-center->Bluetooth. Which means the blocker proposal is relevant. Also proposing as a prioritized bug, this is a highly important issue and sadly receives no attention from the kernel team.

Comment 31 Ben Cotton 2022-08-11 12:15:40 UTC
We'll hold off on the Prioritized Bug evaluation until a blocker determination is made.

Comment 32 Hans de Goede 2022-08-11 13:24:15 UTC
(In reply to Kamil Páral from comment #30)
> I tested with kernel-5.19.0-300.fc37.x86_64 and I don't see any improvement.
> My bluetooth mouse still doesn't reconnect after resume, unless I open
> gnome-control-center->Bluetooth. Which means the blocker proposal is
> relevant. Also proposing as a prioritized bug, this is a highly important
> issue and sadly receives no attention from the kernel team.

I checked and 5.19.0 does not contain the fix which is supposed to fix this, so this not working with that kernel is expected.

I've started a scratch-build of 5.19.0 with the patch fixing this added:
https://koji.fedoraproject.org/koji/taskinfo?taskID=90700542

Note this is still building atm, it should be finished in about 1-2 hours, please test this once it has finished building. If people can confirm this fixes things I'll submit a pull-req to get this added to the official Fedora kernels.

Installation instructions (if necessary):
https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

Comment 33 Hans de Goede 2022-08-11 13:57:49 UTC
The scratch build has completed and the 5.19.0 with the patch added can be downloaded for testing now.

Comment 34 Kamil Páral 2022-08-11 15:18:25 UTC
(In reply to Hans de Goede from comment #32)
> I've started a scratch-build of 5.19.0 with the patch fixing this added:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=90700542

Thanks, Hans. This works perfectly, my mouse is reconnected immediately after resume! Tested 3 times.

> If people can confirm this fixes things I'll submit a pull-req to get this added to the official Fedora kernels.

Can you please also add it to the existing stable release kernels? I'm not sure if it is preferable to patch 5.18.6, or push 5.19 to stable releases, but most of the affected people are surely on stable releases, and we should fix this for them, not just in Rawhide/Branched. Thanks!

(In reply to Ben Cotton from comment #31)
> We'll hold off on the Prioritized Bug evaluation until a blocker
> determination is made.

Well I assumed the PrioritizedBug would be used to push the fix primarily in stable releases, not Branched.

Comment 35 Hans de Goede 2022-08-11 18:44:47 UTC
Merge request for fedora-5.18: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1984
Merge request for fedora-5.19: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1983

I'll also keep an eye out for these landing in 5.20, I expect them to find their way into 5.20 through upstream, but you never know.

Comment 36 Hans de Goede 2022-08-11 19:40:22 UTC
Good news, Justin just merged my 2 merge-requests, so this should be fixed in the next 5.18 resp. 5.19 Fedora kernel build.

Comment 37 Marcel Ziswiler 2022-08-12 07:11:36 UTC
(In reply to Hans de Goede from comment #36)
> Good news, Justin just merged my 2 merge-requests, so this should be fixed
> in the next 5.18 resp. 5.19 Fedora kernel build.

Thanks, Hans. You're the man!

(;-p)

Comment 38 Kamil Páral 2022-08-18 06:18:21 UTC
I'm happy to report that this is indeed fixed in the latest kernel updates:
F35: https://bodhi.fedoraproject.org/updates/FEDORA-2022-b1ca3f2172  (untested)
F36: https://bodhi.fedoraproject.org/updates/FEDORA-2022-c782864bc6  (tested)
F37: https://bodhi.fedoraproject.org/updates/FEDORA-2022-fd414fa957  (tested)

Comment 39 Adam Williamson 2022-08-22 16:28:24 UTC
The F37 update is stable, so we can drop F37 blocker metadata.

Comment 40 Adam Williamson 2022-08-22 16:32:53 UTC
In fact F35 and F36 updates are also stable, so let's close it.