Bug 215768 - Kernel 5.17 can't suspend while bluetooth is enabled.
Summary: Kernel 5.17 can't suspend while bluetooth is enabled.
Status: REOPENED
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Sleep-Wake (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: acpi_power-sleep-wake
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-03-29 04:18 UTC by plum
Modified: 2022-06-21 10:12 UTC (History)
17 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).

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