Attempting to suspend a Dell Latitude 7275 in s2idle state doesn't work, as the system wakes up right away / just after a few seconds. Looking at the default output of /proc/acpi/wakeup, very few entries are enabled: $ cat /proc/acpi/wakeup | grep enabled XHC S0 *enabled pci:0000:00:14.0 LID0 S3 *enabled platform:PNP0C0D:00 PBTN S3 *enabled platform:PNP0C0C:00 Disabling the XHC entry makes the system suspend properly and reliably as a quick workaround, with the following command: # echo XHC > /proc/acpi/wakeup Investigating a bit more by re-enabling the above XHC entry, the culprit seems to be Bluetooth: - switching off Bluetooth before suspend renders suspend stable (in my case from the Gnome Settings) - enabling the Bluetooth radio brings back the spurious wake events right away. Having Bluetooth devices actually connected or not doesn't change this behavior. I don't see any output in the system logs mentioning this wake-up event so I don't know which logs would be useful. Here are some info from dmesg: $ cat dmesg.txt | grep Bluetooth [ 3.949315] Bluetooth: Core ver 2.22 [ 3.949327] Bluetooth: HCI device and connection manager initialized [ 3.949330] Bluetooth: HCI socket layer initialized [ 3.949332] Bluetooth: L2CAP socket layer initialized [ 3.949338] Bluetooth: SCO socket layer initialized [ 3.982814] Bluetooth: hci0: Firmware revision 0.0 build 95 week 37 2016 [ 4.254340] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 4.254342] Bluetooth: BNEP filters: protocol multicast [ 4.254346] Bluetooth: BNEP socket layer initialized [ 9.525978] Bluetooth: RFCOMM TTY layer initialized [ 9.525987] Bluetooth: RFCOMM socket layer initialized [ 9.525992] Bluetooth: RFCOMM ver 1.11 [ 14.950895] Bluetooth: HIDP (Human Interface Emulation) ver 1.2 [ 14.950909] Bluetooth: HIDP socket layer initialized and some more info about the system itself: Dell Latitude 7275 is a 2-in-1 detachable laptop with an Intel Core-M processor (6th gen "Skylake"). There is a similar consumer product branded XPS 12 (9250). The combo Wi-Fi / Bluetooth chipset is the AC 8260 from Intel. $ cat dmesg.txt | grep 8260 [ 3.936492] iwlwifi 0000:6d:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208 I'm attaching a dmesg output, lspci and the content of /proc/acpi/wakeup. Let me know which other inputs would be useful to investigate this issue. Thanks, Jérôme
Created attachment 274517 [details] dmesg
Created attachment 274519 [details] lspci
Created attachment 274521 [details] /proc/acpi/wakeup
Thanks a lot Abhishek. The spurious events are going to be fixed with your patch series: https://lore.kernel.org/patchwork/cover/1208369/ with the 4 commits from 9952d90ea2885d7cbf80cd233f694f09a9c0eaec up to 4867bd007d25a8dfd4ffc558534f7aec8b361789 This series is being planned for v5.7, included from rc1 up to rc5 so far. I've just tested it using the bluetooth-next tree, and I can confirm that this is fixing this bug. I'll close and mark it as fixed once v5.7 is released. Eager to see the 2nd part land to, allowing to set/unset a device as wakeable. Cheers, Jérôme
Confirmed as fixed in v5.7 , thanks again Abhishek.
FYI, there's a few more spurious wake issues being discussed in https://bugzilla.kernel.org/show_bug.cgi?id=207629 (usually occurring when you run suspend stress test)
Thanks for this pointer, I haven't detected this issue on my machine (Dell Latitude 7275) so far, suspend looks reliable with the XHC entry re-enabled.