Laptop wakes from sleep if bluetooth is enabled

Hello all,

EDIT: I’m updating this post with a more detailed description of the real issue.

Two completely different laptops in our office are having the same issue. One laptop is a Lenovo Thinkpad p52s and the other is a Xiaomi Notebook Pro.

If bluetooth is enabled, both laptops immediately wake from suspend via closing the lid OR manually selecting the suspend UI option in Gnome. Selecting the suspend option disables the monitor for about 5 seconds, and then the laptop comes back up immediately. If I disable bluetooth, the laptops suspend perfectly.

The issue appears to persist across kernels 4.14-4.17 and Gnome 3.26 and 3.28. Power settings don’t show anything concerning.

Please provide the output of:

  1. free
  2. cat /etc/fstab
  3. cat /etc/default/grub | grep LINUX_DEFAULT
[brad@merlin-xiaomi-1 ~]$ free
              total        used        free      shared  buff/cache   available
Mem:          15927        4367        8854        1143        2705       10137
Swap:         17529           0       17529

[brad@merlin-xiaomi-1 ~]$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=2A35-7FB7                            /boot/efi      vfat    defaults,noatime 0 2
UUID=08bb8a23-950e-48df-a451-c7f4306c536d /              ext4    defaults,noatime 0 1
UUID=2fa2f801-fa95-43b0-be5a-9d7e6688026a swap           swap    defaults,noatime 0 2
[brad@merlin-xiaomi-1 ~]$ cat /etc/default/grub | grep LINUX_DEFAULT
GRUB_CMDLINE_LINUX_DEFAULT="quiet resume=UUID=2fa2f801-fa95-43b0-be5a-9d7e6688026a"

Power management/Suspend and hibernate

Sorry for the delay.

I need the output of cat /etc/mkinitcpio.conf | grep HOOKS

[brad@merlin-xiaomi-1 ~]$ cat /etc/mkinitcpio.conf | grep HOOKS
# HOOKS
# This is the most important setting in this file.  The HOOKS control the
# order in which HOOKS are added.  Run 'mkinitcpio -H <hook name>' for
#    HOOKS=(base)
#    HOOKS=(base udev autodetect block filesystems)
#    HOOKS=(base udev block filesystems)
#    HOOKS=(base udev block mdadm encrypt filesystems)
#    HOOKS=(base udev block lvm2 filesystems)
HOOKS="base udev autodetect modconf block keyboard keymap resume filesystems fsck"

Well, you seem to have everything in order. The only difference is I have the resume hook immediately after the udev hook, but it probably isn’t the cause for your issue.

To distinguish between a DE and a system problem, try to hibernate from a terminal:
systemctl hibernate

If this doesn’t work post the output of journalctl -xe -p3 -b

If this works you’ll have to solve this at the DE level.

That command does work, so I guess it is definitely a system related problem?

1 Like

If there’s any output from the command please post it here. Also

right after issuing the command.

I’m confused, I thought we only cared about the systemctl hibernate command if the laptop didn’t hibernate on that command? There was no output to that command, and it worked perfectly. Should I be doing the journalctl command with the lid close/suspend button that doesn’t work?

Sorry, by reading the last part of the above sentence I missed the “does work” part. If that command works, than it isn’t a system problem. The problem lies in your DE. I’m not experienced with Gnome. You can set the behavior you want using shortcuts or rules and overriding Gnome settings. But maybe someone more knowledgeable about Gnome can help you on this.

EDIT: reproduce the failed hibernation using Gnome and then post the output of journalctl -xe -p3 -b

Update: We’ve determined that this issue is related to Bluetooth being enabled, and it persists across two completely different laptops models in our office (see original post, which I’ve updated).

This seems like a Gnome or Manjaro bug.

You will need to unload the Bluetooth modules before suspending, and then load the Bluetooth modules after resume. This can be done by creating systemd unit files and scripts to load/ unload your Bluetooth modules. Substitute your Bluetooth modules for the wifi modules in the example scripts in the following thread:


You may also find this can be cured by testing different kernels, good luck.

1 Like

Eeek… thanks, @tbg.

In that link, it doesn’t mention how to write the start script. Do you mind sharing the differences to get the script to load the module on resume? Or a link that explains that?

EDIT: Also, and idea which is the correct bluetooth module to unload? I tried:

modprobe -r bluetooth

which led to no change in the behavior. Laptop is still resuming immediately upon suspend.

The script is simply the relevant modprobe commands that work to unload/load your bluetooth modules.

I don’t know which bluetooth modules your laptops use. I would assume “btusb”.

Before suspend.

sudo modprobe -r btusb

After resume:

sudo modprobe btusb

Run each command before suspend & then after resume to test if it works correctly.

To find which bluetooth modules are loaded run an “lsmod” command. Any modules with “bt” in the name are likely involved. Try adding them to your modprobe commands until it works for you.

Make sure you do this^^

1 Like

So… progress. The unloading part is working with btusb, and it is successfully suspending. However, the loading of the module after resume isn’t working and I can’t figure out why…

Here are my two resume related files:

/usr/bin/bluetooth-resume.sh

#!/bin/bash
modprobe btusb

/etc/systemd/system/bluetooth-resume.service

[Unit]
Description=Bluetooth module suspend helper
Before=sleep.target

[Service]
Type=simple
ExecStart=-/usr/bin/bluetooth-resume.sh

[Install]
WantedBy=sleep.target

I also ran the following commands after creating those two resume scripts:

[brad@merlin-xiaomi-1 ~]$ sudo chown root:root /usr/bin/bluetooth-resume.sh
[brad@merlin-xiaomi-1 ~]$ sudo chmod +x /usr/bin/bluetooth-resume.sh
[brad@merlin-xiaomi-1 ~]$ sudo systemctl enable bluetooth-resume.service
Created symlink /etc/systemd/system/sleep.target.wants/bluetooth-resume.service → /etc/systemd/system/bluetooth-resume.service.
[brad@merlin-xiaomi-1 ~]$ sudo systemctl start bluetooth-resume.service
[brad@merlin-xiaomi-1 ~]$ sudo chown root:root /etc/systemd/system/bluetooth-resume.service
[brad@merlin-xiaomi-1 ~]$ sudo chmod +x /etc/systemd/system/bluetooth-resume.service
[brad@merlin-xiaomi-1 ~]$ sudo systemctl enable bluetooth-resume.service
[brad@merlin-xiaomi-1 ~]$ sudo systemctl start bluetooth-resume.service

After resuming, modprobe btusb does bring back my bluetooth when run manually.

As for the kernel side of it… I’ve already tried 4.14, 4.16, and 4.17 with no dice :frowning:

Other bluetooth related modules may be required to be loaded before btusb. Check your lsmod output as I stated earlier.

ps. nicely done on not requiring hand holding creating the required files.

1 Like

I’m on my phone. Hard to read complicated outputs. It looks like you forgot to make the resume script executable.

(edit) Sorry, bad vision.

Does the resume script work if called via sudo from the terminal.

systemctl status bluetooth-resume.service

Forum kindly sponsored by