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.
Created attachment 1892409 [details] dmesg
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.
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.
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
Still happening with kernel-5.18.7-200.fc36.x86_64
...after upgrading today, still happening also with kernel-5.18.10-200.fc36.x86_64
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
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.
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.
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.
I can confirm this same bad behavior with Intel Corp. AX201 Bluetooth controller and 5.18.11-200.fc36.x86_64.
Updated to kernel-5.18.13-200.fc36.x86_64, still happening.
I confirm this issue
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
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.
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.
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.
These seem to be relevant bug reports: https://bugzilla.kernel.org/show_bug.cgi?id=216314 https://github.com/bluez/bluez/issues/373
(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.
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.
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
(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.
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.
I've applied the patch and it's made no difference for me unfortunately.
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
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.
@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.
F37's already on kernel 5.19, so this probably doesn't need to be a blocker for F37...
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
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.
We'll hold off on the Prioritized Bug evaluation until a blocker determination is made.
(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
The scratch build has completed and the 5.19.0 with the patch added can be downloaded for testing now.
(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.
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.
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.
(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)
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)
The F37 update is stable, so we can drop F37 blocker metadata.
In fact F35 and F36 updates are also stable, so let's close it.