Bug 198993

Summary:	Intel Bluetooth 8260: Spurious wake events prevent from staying suspended in s2idle state on Dell Latitude 7275
Product:	Drivers	Reporter:	Jérôme de Bretagne (jerome.debretagne)
Component:	Bluetooth	Assignee:	linux-bluetooth (linux-bluetooth)
Status:	RESOLVED CODE_FIX
Severity:	normal	CC:	abhishekpandit, leho
Priority:	P1
Hardware:	Intel
OS:	Linux
Kernel Version:	5.6 5.5 4.16rc7 4.15rc8 4.14 4.13	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	dmesg lspci /proc/acpi/wakeup

Description Jérôme de Bretagne 2018-03-04 15:25:55 UTC

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

Comment 1 Jérôme de Bretagne 2018-03-04 15:27:03 UTC

Created attachment 274517 [details]
dmesg

Comment 2 Jérôme de Bretagne 2018-03-04 15:27:33 UTC

Created attachment 274519 [details]
lspci

Comment 3 Jérôme de Bretagne 2018-03-04 15:28:06 UTC

Created attachment 274521 [details]
/proc/acpi/wakeup

Comment 4 Jérôme de Bretagne 2020-05-12 21:13:04 UTC

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

Comment 5 Jérôme de Bretagne 2020-07-06 20:29:10 UTC

Confirmed as fixed in v5.7 , thanks again Abhishek.

Comment 6 Abhishek Pandit-Subedi 2020-07-06 20:41:12 UTC

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)

Comment 7 Jérôme de Bretagne 2020-07-06 21:00:45 UTC

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.