Bug 215768 - Kernel 5.17 can't suspend while bluetooth is enabled.
Summary: Kernel 5.17 can't suspend while bluetooth is enabled.
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Bluetooth (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: linux-bluetooth@vger.kernel.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-03-29 04:18 UTC by plum
Modified: 2022-09-09 07:17 UTC (History)
23 users (show)

See Also:
Kernel Version: 5.17 and 5.18
Tree: Mainline
Regression: No


Attachments
Log from gnome-log. Twice suspend with bluetooth on and once with bluetooth disabled. (625.56 KB, application/octet-stream)
2022-03-29 04:18 UTC, plum
Details
btmon output (7.19 KB, application/octet-stream)
2022-05-10 18:49 UTC, Emanuele Melzi
Details
btmon output on xps 15 (2.17 KB, application/octet-stream)
2022-05-10 19:25 UTC, Damien Thébault
Details
btmon output on xps 15, shorter screen off time (1.94 KB, application/octet-stream)
2022-05-10 19:26 UTC, Damien Thébault
Details
btmon output on xps 15 with 5.18-rc6 (1.76 KB, application/octet-stream)
2022-05-10 20:52 UTC, Damien Thébault
Details

Description plum 2022-03-29 04:18:20 UTC
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.
Comment 1 plum 2022-04-01 01:22:31 UTC
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
Comment 2 plum 2022-04-08 00:27:15 UTC
This issue is fixed on Kernel 5.18 rc1
Comment 3 plum 2022-04-09 12:11:25 UTC
oh. It seems kernel 5.18 rc1 still have this issue.
But can confirm that disable bluetooth can solve it.
Comment 4 Emanuele Melzi 2022-04-09 15:44:00 UTC
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.
Comment 5 Damien Thébault 2022-05-04 20:41:20 UTC
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.
Comment 6 sviperz 2022-05-07 09:53:18 UTC
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.
Comment 7 Luiz Von Dentz 2022-05-10 17:56:12 UTC
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.
Comment 8 Emanuele Melzi 2022-05-10 18:49:18 UTC
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.
Comment 9 Damien Thébault 2022-05-10 19:25:32 UTC
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.
Comment 10 Damien Thébault 2022-05-10 19:26:04 UTC
Created attachment 300923 [details]
btmon output on xps 15, shorter screen off time
Comment 11 Luiz Von Dentz 2022-05-10 19:51:58 UTC
(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
Comment 12 Luiz Von Dentz 2022-05-10 19:59:43 UTC
(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.
Comment 13 Damien Thébault 2022-05-10 20:52:55 UTC
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.
Comment 14 Luiz Von Dentz 2022-05-11 06:08:07 UTC
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
Comment 15 Damien Thébault 2022-05-11 08:49:05 UTC
(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).
Comment 16 Luiz Von Dentz 2022-05-11 20:11:54 UTC
(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.
Comment 17 Luiz Von Dentz 2022-05-12 23:53:49 UTC
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/
Comment 18 Damien Thébault 2022-05-13 08:07:44 UTC
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
Comment 19 plum 2022-05-17 10:24:26 UTC
It seems this issue is fixed in BlueZ.
So should we wait for a new bluez version released or new kernel?
Comment 20 ifaigios 2022-05-27 13:26:43 UTC
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?
Comment 21 Reik Keutterling 2022-05-30 18:27:12 UTC
(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.
Comment 22 Damien Thébault 2022-06-06 06:47:51 UTC
It has been merged and is now available in v5.19-rc1.
I just tested and it suspends properly on this tag.
Comment 23 plum 2022-06-16 00:29:00 UTC
Can confirm fixed in kernel 5.18.4
Comment 24 ifaigios 2022-06-16 12:08:51 UTC
Still not fixed for me in linux-5.18.4 on Thinkpad X1 Carbon Gen 9
Comment 25 Damien Thébault 2022-06-20 08:26:27 UTC
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.
Comment 26 Roberto 2022-06-20 11:53:44 UTC
(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!
Comment 27 Tomas Janousek 2022-06-20 11:58:20 UTC
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
Comment 28 Damien Thébault 2022-06-20 12:25:20 UTC
(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.
Comment 29 Krzysztof.Krason 2022-06-21 10:11:40 UTC
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.
Comment 30 Krzysztof.Krason 2022-06-21 10:12:54 UTC
Kernel 5.18.5 (onm 5.18.3 I have resume issues, didn't test 5.18.4).
Comment 31 Zhang Rui 2022-06-27 03:14:47 UTC
reassign to bluetooth experts.
Comment 32 ifaigios 2022-07-09 13:27:23 UTC
Problem persists in 5.18.10 on Thinkpad X1 Carbon Gen 9, having bluetooth devices connected  makes the laptop wake up immediately after suspending.
Comment 33 teleyinex 2022-08-04 08:28:18 UTC
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.
Comment 34 woky 2022-08-04 22:15:09 UTC
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!
Comment 35 plum 2022-08-05 01:21:55 UTC
Can confirm fixed in Kernel 5.18.16
Comment 36 teleyinex 2022-08-05 07:35:59 UTC
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.
Comment 37 Krzysztof.Krason 2022-08-14 20:52:45 UTC
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)
Comment 38 Krzysztof.Krason 2022-08-23 10:16:02 UTC
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.
Comment 39 Damien Thébault 2022-08-23 11:58:47 UTC
I can confirm that on 5.19.2 I'm able to connect bluetooth devices after wake-up without having to stop/start bluetooth.
Comment 40 ifaigios 2022-09-02 12:27:16 UTC
Bug fixed in linux-5.19.2, time to close this
Comment 41 Michael Guntsche 2022-09-05 20:11:18 UTC
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.
Comment 42 Paul Menzel 2022-09-05 20:39:52 UTC
Michael, thank you for your report, please open a new issue though. (And it would be great, if you could bisect the issue.)
Comment 43 Michael Guntsche 2022-09-09 06:40:33 UTC
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.
Comment 44 plum 2022-09-09 07:13:47 UTC
It's fixed in Kernel 5.19.
Comment 45 Michael Guntsche 2022-09-09 07:17:50 UTC
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.

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