System wakes up immediately after suspend if Bluetooth is still enabled

Bug #1823076 reported by b on 2019-04-03
50
This bug affects 9 people
Affects Status Importance Assigned to Milestone
bluez (Ubuntu)
Undecided
Unassigned
linux (Ubuntu)
Undecided
Unassigned

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: USB
  BD Address: 00:BB:60:50:92:5D ACL MTU: 1021:4 SCO MTU: 96:6
  UP RUNNING
  RX bytes:1912660 acl:106009 sco:0 events:337 errors:0
  TX bytes:12331 acl:74 sco:0 commands:204 errors:0

b (ben-ekran) wrote :

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?

summary: - Intel NUC (8I3BEH1) wakes up immediately after suspend after installing
- BlueZ
+ Intel NUC (8I3BEH1) wakes up immediately after suspend if Bluetooth is
+ still enabled
Daniel van Vugt (vanvugt) wrote :

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

Changed in bluez (Ubuntu):
status: New → Incomplete
b (ben-ekran) wrote :

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.

Changed in bluez (Ubuntu):
status: Incomplete → Invalid
b (ben-ekran) wrote :

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.

Changed in bluez (Ubuntu):
status: Invalid → Incomplete
b (ben-ekran) wrote :

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.

b (ben-ekran) wrote :

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

Changed in bluez (Ubuntu):
status: Incomplete → New
summary: - Intel NUC (8I3BEH1) wakes up immediately after suspend if Bluetooth is
- still enabled
+ System wakes up immediately after suspend if Bluetooth is still enabled
Launchpad Janitor (janitor) wrote :

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

Changed in bluez (Ubuntu):
status: New → Confirmed
Jiri Kanicky (jirik) wrote :

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.

Changed in linux (Ubuntu):
status: New → Confirmed
Jiri Kanicky (jirik) wrote :

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.

Vadym Abramchuck (abramzzz) wrote :

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.

Kai-Heng Feng (kaihengfeng) wrote :

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"

Matthias (mbargmann) wrote :

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.

Kai-Heng Feng (kaihengfeng) wrote :

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

Matthias (mbargmann) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers