Bug 215768
| Summary: | Kernel 5.17 can't suspend while bluetooth is enabled. | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | plum (plumerlis) |
| Component: | Bluetooth | Assignee: | linux-bluetooth (linux-bluetooth) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | damien.thebault, ifaigios, itsbytebites, jeremy, kernel, Krzysztof.Krason, leodream2008, luiz.dentz, marcel, mike, mikerogerz, mpagano, nechtom, pmenzel+bugzilla.kernel.org, prettyvanilla, r087r70, robinlee.sysu, rui.zhang, s.viper.z, serhii.tsynailo, spielkind, teleyinex, tomi |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 5.17 and 5.18 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
Log from gnome-log. Twice suspend with bluetooth on and once with bluetooth disabled.
btmon output btmon output on xps 15 btmon output on xps 15, shorter screen off time btmon output on xps 15 with 5.18-rc6 |
||
Someone said disable Always on USB can solove this issue. I tried and it works. https://bbs.archlinux.org/viewtopic.php?id=274292&p=2 This issue is fixed on Kernel 5.18 rc1 oh. It seems kernel 5.18 rc1 still have this issue. But can confirm that disable bluetooth can solve it. Can confirm this is also happening on Xiaomi Mi Notebook Pro 2020 on 5.17 (regular suspend, not s2idle), whereas it worked on 5.16. Turning off bluetooth solves it. I have the issue on my Dell XPS 15. I did a bisect session between 5.16 and 5.17 to track down the problem. I ended with this "bad" commit that made suspend not work anymore: 80740ebb7e1ad15ab9c11425dcd26e073f86d74b Bluetooth: hci_sync: Fix hci_update_accept_list_sync And indeed, I tested again on 5.17.5 without this change and it suspends properly. Being a commit about bluetooth, it seems consistent with the fact that disabling bluetooth makes the issue go away. Have the same issue on ASUS ZenBook UX325EA. And yes, both switching off bluetooth and going back to 5.16 resolve the issue. Hope it will be fixed in 5.18. Can someone add the HCI trace (e.g. btmon -w <file>) when the issue happens, if is something related to Accept List perhaps there is a HCI command failing for some reason. Created attachment 300921 [details]
btmon output
btmon output on Mi Notebook Pro 2020 (Kernel 5.17.5 on Fedora 36) while the issue is happening. Suspend command should be at around 11 seconds and it resumed itself shortly after.
Created attachment 300922 [details]
btmon output on xps 15
btmon output on my xps 15, I think the syspend is at around 10s (maybe around "Controller Suspended").
The computer screen stayed off for a few seconds and came back afterwards.
I made a second capture where it slept less, and the only difference is the time between "Controller Suspended" and the next event.
Created attachment 300923 [details]
btmon output on xps 15, shorter screen off time
(In reply to Emanuele Melzi from comment #8) > Created attachment 300921 [details] > btmon output > > btmon output on Mi Notebook Pro 2020 (Kernel 5.17.5 on Fedora 36) while the > issue is happening. Suspend command should be at around 11 seconds and it > resumed itself shortly after. < HCI Command: Create Connection Cancel (0x01|0x0008) plen 6 #20 [hci0] 12.286006 Address: 00:01:02:00:00:6D (3COM) > HCI Event: Command Complete (0x0e) plen 10 > #21 > [hci0] 12.286988 Create Connection Cancel (0x01|0x0008) ncmd 1 Status: Unknown Connection Identifier (0x02) Address: 00:01:02:00:00:6D (3COM) This should have been fixed already by the following change: https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/commit/?id=c86cc5a3ec70f5644f1fa21610b943d0441bc1f7 (In reply to Damien Thébault from comment #10) > Created attachment 300923 [details] > btmon output on xps 15, shorter screen off time Looks like it the same problem as above, due to invalid handle sent by the controller a connection could not be cleanup properly so we attempt to cancel it when suspending but then the controller return an error. We already submitted a set for inclusion on 5.18 via bluetooth.git: https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/ Since this is quite recent change perhaps it hasn't reached the stable trees yet. Created attachment 300924 [details]
btmon output on xps 15 with 5.18-rc6
Thank you for having a look.
Indeed my previous captures were done on archlinux with kernel 5.17.5, and the change you mention has been merged in linux 5.18-rc5.
Here is a similar capture on a custom-built 5.18-rc6, with suspend at around 12s, it doesn't suspend properly unfortunately.
Let me know if you need additional debug.
Weird, there is still the same error: > HCI Event: Command Complete (0x0e) plen 10 > #21 > [hci0] 12.286988 Create Connection Cancel (0x01|0x0008) ncmd 1 Status: Unknown Connection Identifier (0x02) Either that doesn't really contain the fixes or that didn't make a difference which would be quite weird given the changes do ensure the hci_conn_del is called: https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/commit/?id=c86cc5a3ec70f5644f1fa21610b943d0441bc1f7 (In reply to Luiz Von Dentz from comment #14) > Weird, there is still the same error I have checked with btmon on my side, but I get the "Unknown Connection Identifier" only in Emanuele attachment 300921 [details] (Fedora 36 kernel 5.17.5 Mi Notebook Pro 2020), but not in mine (Archlinux kernel 5.17.5/5.18-rc6 Dell XPS 15 9510). (In reply to Damien Thébault from comment #15) > (In reply to Luiz Von Dentz from comment #14) > > Weird, there is still the same error > > I have checked with btmon on my side, but I get the "Unknown Connection > Identifier" only in Emanuele attachment 300921 [details] (Fedora 36 kernel > 5.17.5 Mi Notebook Pro 2020), but not in mine (Archlinux kernel > 5.17.5/5.18-rc6 Dell XPS 15 9510). Sorry for the confusion, it seems I was reading the wrong file, in your case the error is actually: @ MGMT Event: Controller Resumed (0x002e) plen 8 {0x0001} [hci0] 14.868056 Wake reason: Wake due to unexpected event (1) Address: 30-FE-A5-D9-5C-02 It seems it is being wakeup by some event, there is indeed events after: @ MGMT Event: Controller Suspended (0x002d) plen 1 {0x0001} [hci0] 12.491034 Suspend state: Disconnected and not scanning (1) It doesn't seem we send any command to stop scanning so it looks like it out of sync with respect to scanning state and on resume it does send a command to start scanning, what could explain this is something other entity attempting to control the scanning state. I submit a series to attempt to fix this: https://patchwork.kernel.org/project/bluetooth/list/?series=641172 There is a also a patch for userspace but it doesn't fix the issues by itself: https://patchwork.kernel.org/project/bluetooth/patch/20220512234835.1042988-1-luiz.dentz@gmail.com/ Thank you, I tested the kernel patches against 5.18-rc6 and it does fix the issue on my computer. I didn't try the userspace patch, I tested with bluez 5.64 It seems this issue is fixed in BlueZ. So should we wait for a new bluez version released or new kernel? Issue still persists with linux-5.18 on Thinkpad X1 Carbon Gen 9. This bug is a clear regression introduced by linux-5.17. How are the relevant commits still not reverted or a fix introduced one major release later? (In reply to Luiz Von Dentz from comment #17) > I submit a series to attempt to fix this: > > https://patchwork.kernel.org/project/bluetooth/list/?series=641172 > I'm unsure is this already merged to linux-next to be going released with 5.19, and a possible merge into 5.18? Or where can I see the state of the merge, sorry I'm not that familiar with the kernel development. It has been merged and is now available in v5.19-rc1. I just tested and it suspends properly on this tag. Can confirm fixed in kernel 5.18.4 Still not fixed for me in linux-5.18.4 on Thinkpad X1 Carbon Gen 9 Tested on my XPS 15 9510 with 5.18.5 (archlinux) and it seems better than before, because now it can actually suspend out of the box, which is great. But if a bluetooth device is connected when suspending, then it doesn't suspend and starts back again immediately. (In reply to Damien Thébault from comment #25) > Tested on my XPS 15 9510 with 5.18.5 (archlinux) and it seems better than > before, because now it can actually suspend out of the box, which is great. > > But if a bluetooth device is connected when suspending, then it doesn't > suspend and starts back again immediately. then how is it better than before? it seems still not fixed in 5.18.5! As a temporary workaround, I have a script that disconnects bluetooth devices before suspend. Sharing in case it's useful for others. /lib/systemd/system-sleep/liskin-bluetooth-disconnect: https://github.com/liskin/dotfiles/blob/fd4787f2fd2bda3792e4ffd25a8cdcc6471fc963/usr/lib/systemd/system-sleep/liskin-bluetooth-disconnect (In reply to Roberto from comment #26) > then how is it better than before? it seems still not fixed in 5.18.5! Before, just having bluetooth enabled was enough to make it not suspend. Now you need to have something connected to make it not suspend. Tested on myy Dell Precision 5560, now I have my suspend back, thank you. But, there is another issue: my bluetooth devices don't reconnect on resume. They do connect when I reboot, but after resume I have to manually connect them. Kernel 5.18.5 (onm 5.18.3 I have resume issues, didn't test 5.18.4). reassign to bluetooth experts. Problem persists in 5.18.10 on Thinkpad X1 Carbon Gen 9, having bluetooth devices connected makes the laptop wake up immediately after suspending. The problem persists in 5.18.15 on X1 Carbon Gen 6, having Bluetooth devices connected makes the laptop wake up immediately after suspending as ifaglos reported. The problem seems to be fixed by commit d50f2557 ("Bluetooth: Always set event mask on suspend") present in 5.18.16. At least on my box (Asus ZenBook UX410) it doesn't resume few seconds after suspend with bluetooth headset connected anymore. Thanks!
Can confirm fixed in Kernel 5.18.16 Can confirm it is fixed in Kernel 5.18.16. What I now need to know why after resuming the Bluetooth does not connect the devices unless I open gnome control center and activate Bluetooth. According to systemcl Bluetooth daemon is running. In my case it also doesn't reconnect to BT devices, I need to manually connect to them after resume (5.18.12 - the fix for resume worked for me since 5.18.5, but with the reconnection issue) Reconnecto to BT devices started working again in 5.19.3 for me (probably 5.19.2 would be enough because I've seen a lot of BT fixes there) in 5.19.1 it didn't work. I can confirm that on 5.19.2 I'm able to connect bluetooth devices after wake-up without having to stop/start bluetooth. Bug fixed in linux-5.19.2, time to close this Hi, this worked for me in 5.19.3 but stopped working in 5.19.5 again. With 5.19.3 I could go into standby with my BT headphones connected, with 5.19.5 and 6.0-rc3 the machine does not go to standby. Michael, thank you for your report, please open a new issue though. (And it would be great, if you could bisect the issue.) Hello, For your information, I tried this a little bit more and for me suspend only works if I add the script mentioned in https://bugzilla.kernel.org/show_bug.cgi?id=215768#c27 to my setup. If the bluetooth devices are not removed prior to suspend it hangs. It's fixed in Kernel 5.19. Sorry I forgot to mention, I tried this with 5.19.8 and without the script my notebook does not suspend correctly, well it does every now and then but it is not deterministic. With the script it always works. |
Created attachment 300635 [details] Log from gnome-log. Twice suspend with bluetooth on and once with bluetooth disabled. ThinkPad X1 Carbon 9th with latest bios. Kernel 5.17.1 X64 Fedora 36 X64 prebeta Gnome 42.0 rc After upgrade to kernel 5.17 rc8 or kernel 5.17.1, My laptop can't get to suspend. It seems will get it but wakeup immediately after that. I trid to disabled bluetooth and everything works okay. Downgrade to Kernel 5.16 also can solve this issue.