System wakes up immediately after suspend if Bluetooth is still enabled

It sounds like you've found a good workaround but I am curious about the root cause here.

It seems the Bluetooth mouse might be emitting events even when you don't touch it..? Are you able to try a different model of Bluetooth mouse?

Also, are you able to change any settings in your BIOS to prevent wakeup from Bluetooth?

I believe this issue was due to "legacy suspend" rather than "modern suspend" selected in UEFI. After a couple suspends I am no longer seeing the problem, but will reopen if it happens again.

Scratch that; the first couple suspend operations did work, and then they stopped again. I'll do more testing and report back. I did rule out mouse movement by using the hardware power switch on the mouse.

So after some more investigation it's clear that the problem is inconsistent. Sometimes wake immediately follows suspend, sometimes not. Sometimes it takes a while to wake up, up to a few minutes, other times it's immediate. Occasionally, it seems to suspend fine; or maybe I'm not waiting long enough for the wake.

I noticed also that I can't stop bluetoothd:

$ ps aux | grep bluetoothd
root 8305 0.0 0.0 36520 4388 ? Ss 11:35 0:00 /usr/lib/bluetooth/bluetoothd -d
bbogart 8598 0.0 0.0 22000 1040 pts/2 R+ 11:40 0:00 grep --color=auto bluetoothd
$ sudo service bluetooth stop
$ ps aux | grep bluetoothd
root 8662 2.5 0.0 36520 4324 ? Ss 11:41 0:00 /usr/lib/bluetooth/bluetoothd -d
bbogart 8670 0.0 0.0 22000 1088 pts/2 S+ 11:41 0:00 grep --color=auto bluetoothd

Why would bluetoothd restart after I've explicitly told it to stop?

Now, if I put the stop and start service script in /lib/systemd/system-sleep/, then the NUC does not wake up after hours.

The problem persists when:
Mouse is switched off (before entering suspend)
Mouse is changed to USB (not BT) mode
Bluetooth is turned "off" (via blueman applet)

Removing bluez may also solve the problem, I'm testing that now.

If I remove the bluez package there are no issues with suspend.

Status changed to 'Confirmed' because the bug affects multiple users.

I think this issue is reproducible on laptops which do not have S3 system state, but rather use S0ix (like Dell XPS).

As S0ix (Suspend-to-Idle) is used the system is woken up from this state by in-band interrupts, so theoretically any devices that can cause interrupts to be generated in the working state can also be set up as wakeup devices for S2Idle.

I tested it on XPS 15 7590 and I can confirm the issue. If I disable bluetooth before suspend, suspend works fine.

You can use the following workaround.

List devices which can wake up the notebook from sleep:

# cat /proc/acpi/wakeup | grep enable
PEG0 S4 *enabled pci:0000:00:01.0
RP01 S4 *enabled pci:0000:00:1c.0
RP05 S4 *enabled pci:0000:00:1c.4
RP09 S4 *enabled pci:0000:00:1d.0
RP17 S4 *enabled pci:0000:00:1b.0
PXSX S4 *enabled pci:0000:02:00.0
XHC S0 *enabled pci:0000:00:14.0
LID0 S3 *enabled platform:PNP0C0D:00
PBTN S3 *enabled platform:PNP0C0C:00

Look for XHC device. You can match the device by running "lspci"

Disable wakeup
# echo XHC > /proc/acpi/wakeup

If I send the notebook to sleep "echo freeze > /sys/power/state" it should stay in sleep even if you move BT mouse or hit key on BT keyboard.

I can confirm the same is happening to me at Disco running on Dell XPS 13 9380.

Disabling wakeup for XHC a sort of helps, however, it also disables wakeup for a touchpad; I suppose this is because pci:0000:00:14.0 is a USB controller so everything under USB bus is disabled.

Please test latest mainline kernel:
https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.3/

Particularly, this commit:
commit 1ffdb51f28e8ec6be0a2b812c1765b5cf5c44a8f
Author: Mario Limonciello <email address hidden>
Date: Mon Aug 19 12:04:08 2019 -0500

    Revert "Bluetooth: btusb: driver to enable the usb-wakeup feature"

I have the same problem on my Lenovo T480s with Xubuntu 19.04. Disabling Bluetooth helps as a workaraound.
I also tried the mainline kernel 5.3.2 with the exact same result.

"Same result" here means it doesn't wake up anymore?

"Same Result" means it wakes up a few seconds after sleep. With bluetooth disabled, it stays in sleep as expected.

Newer firmwares [1] may be required.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/

I am having this issue also. Turning off bluetooth with bluez (Bluetooth Manager) applet icon and manually stopping bluetooth service the suspend works. Otherwise I have seen suspends but usually just wakes up in a few seconds. Lenovo P53 with Ubuntu 19.10 and kernel 5.3.0-24-generic

Please power off your laptop completely and power it on again after 1
minute. Paste dmesg log since boot and your linux-firmware version, then we
may know which file to fix.

smartman <email address hidden> 於 2019年12月27日 週五 00:55 寫道：

> I am having this issue also. Turning off bluetooth with bluez (Bluetooth
> Manager) applet icon and manually stopping bluetooth service the suspend
> works. Otherwise I have seen suspends but usually just wakes up in a few
> seconds. Lenovo P53 with Ubuntu 19.10 and kernel 5.3.0-24-generic
>
> --
> You received this bug notification because you are subscribed to linux
> in Ubuntu.
> https://bugs.launchpad.net/bugs/1823076
>
> Title:
> System wakes up immediately after suspend if Bluetooth is still
> enabled
>
> Status in bluez package in Ubuntu:
> Confirmed
> Status in linux package in Ubuntu:
> Confirmed
>
> Bug description:
> After replacing my USB mouse with a BT mouse, I noticed my machine
> would no longer suspend without immediately waking up. i.e. I suspend
> and see the light go into the slow fade in and out for one cycle and
> then goes solid and the display wakes up again. If I disable BT (via
> blueman applet) suspend works fine.
>
> I've fixed this by shutting down the BT service before suspend, and
> starting it back up on wake, as indicated here:
> https://askubuntu.com/questions/797590/ubuntu-wakes-up-immediately-
> after-suspend
>
> Perhaps this script should be included in blueZ as suspend issues seem
> very hard to debug and the immediate wake after suspend could be
> caused many any number of things.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 18.04
> Package: bluez 5.48-0ubuntu3.1 [modified:
> lib/systemd/system/bluetooth.service]
> ProcVersionSignature: Ubuntu 4.15.0-46.49-generic 4.15.18
> Uname: Linux 4.15.0-46-generic x86_64
> ApportVersion: 2.20.9-0ubuntu7.6
> Architecture: amd64
> CurrentDesktop: XFCE
> Date: Wed Apr 3 13:16:14 2019
> InstallationDate: Installed on 2019-02-09 (53 days ago)
> InstallationMedia: Xubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64
> (20180725)
> InterestingModules: rfcomm bnep btusb bluetooth
> MachineType: Intel(R) Client Systems NUC8i3BEH
> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-46-generic
> root=UUID=9c982b36-8142-4719-810a-e06f81cab223 ro quiet splash vt.handoff=1
> SourcePackage: bluez
> UpgradeStatus: No upgrade log present (probably fresh install)
> dmi.bios.date: 10/15/2018
> dmi.bios.vendor: Intel Corp.
> dmi.bios.version: BECFL357.86A.0051.2018.1015.1513
> dmi.board.name: NUC8BEB
> dmi.board.vendor: Intel Corporation
> dmi.board.version: J72693-304
> dmi.chassis.type: 3
> dmi.chassis.vendor: Intel Corporation
> dmi.chassis.version: 2.0
> dmi.modalias:
> dmi:bvnIntelCorp.:bvrBECFL357.86A.0051.2018.1015.1513:bd10/15/2018:svnIntel(R)ClientSystems:pnNUC8i3BEH:pvrJ72753-303:rvnIntelCorporation:rnNUC8BEB:rvrJ72693-304:cvnIntelCorporation:ct3:cvr2.0:
> dmi.product.family: Intel NUC
> dmi.product.name: NUC8i3BEH
> dmi.product.version: J72753-303
> dmi.sys.vendor: Intel(R) Client Systems
> hciconfig:
> hci0: Type: Primary Bus: US...

Same bug here. I'm using a Lenovo X1 Carbon 6th Gen.
Operating System: Kubuntu 19.10
KDE Plasma Version: 5.18.3
KDE Frameworks Version: 5.67.0
Qt Version: 5.12.4
Kernel Version: 5.3.0-46-generic
OS Type: 64-bit
Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz
Memory: 15.4 GiB of RAM

linux-firmware: 1.183.5

Suspend works fine if I turn off the Bluetooth before closing the lid. Otherwise it wakes up by itself.

A fix for this issue is planned for v5.7, included from rc1 up to rc5 so far, with this patch series: https://lore.kernel.org/patchwork/cover/1208369/ and the 4 commits from 9952d90ea2885d7cbf80cd233f694f09a9c0eaec up to 4867bd007d25a8dfd4ffc558534f7aec8b361789

I had created a bug about this a while ago here: https://bugzilla.kernel.org/show_bug.cgi?id=198993
and I've just confirmed that the patch series is indeed fixing this issue on my system (a Dell Latitude 7275).

I'm expecting this will cover most/all of the other systems mentioned in this discussion too. I hope this sharing will be useful for some of you.

Cheers,
Jérôme

PPA: https://launchpad.net/~vicamo/+archive/ubuntu/ppa-1823076

@Jerome, could you help testing my backport of the patches you mentioned to v5.6 in https://launchpad.net/~vicamo/+archive/ubuntu/ppa-1823076:

  $ sudo add-apt-repository ppa:vicamo/ppa-1823076
  $ sudo apt install linux-image-unsigned-5.6.0-1010-oem=5.6.0-1010.10+lp1823076 \
      linux-modules-5.6.0-1010-oem=5.6.0-1010.10+lp1823076

If that also works for you, we can begin SRU process to fix this issue in Ubuntu.

Hi You-Sheng,

Sorry for this very late feedback, I just saw your message a few minutes ago as I was not subscribed to this bug.

I've now tested your backport of the patches and I can confirm that it is indeed working on my machine (Dell Latitude 7275).

FYI, I was also pointed out that there is an on-going discussion about suspend failures following these patches, details here: https://bugzilla.kernel.org/show_bug.cgi?id=207629
but I'm not seeing this issue in my case.

Cheers,
Jérôme

Hi Jérôme,

Apparently I missed your message as well.

These patches have been included in kernel v5.7, and oem-6.0 has EOL-ed.