Suspend not working any more on qzed's 5.2.5 build

[shadowrylander]

Hello!
     I am using @qzed's latest 5.2.5 release 1 build, and I seem to have lost the ability to suspend my device; I close the lid, then pull it open a while later, and it's just as warm as when it started, instead of freezing cold, waking up a bit too quickly to have been suspended at all. I haven't changed anything kernel-related since I installed the build (does undocking and redocking for the first time since I installed the kernel count?), and I know the powerbutton isn't being pressed, as it's just sitting on my desk. In addition, how do I get the kernel logs related to whether it was suspended or not?
Any help on the matter would be greatly appreciated!

P.S. : WiFi module seems to disconnect when the lid is closed, and disappearing from the settings entirely at times, forcing me to reboot. Do I open a new issue for this? Bluetooth disconnects on lid close as well, though doesn't disappear from the settings.

[shadowrylander]

Will something like the solution here work? https://askubuntu.com/a/1152359

[shadowrylander]

UPDATE: It appears as though the Bluetooth module is constantly waking up the Surface. Anything I can do about that? Other than constantly turning off bluetooth before suspending?

[tmarkov]

Try this: https://github.com/jakeday/linux-surface/wiki/Frequently-Asked-Questions#my-device-wakes-up-automatically-from-suspendhibernate

EDIT: Though if the page you linked above didn't help, this wouldn't help either. The systemd service is mainly a way to make the changes to the /sys/.../power/wakeup survive reboot. The bluetooth wakeup should be at /sys/bus/pci/devices/0000:00:1d.3/power/wakeup

[alturismo]

may a hint where to get the 525 kernel from ?

i d like to test on ubuntu 19 on surface laptop.

thanks ahead

[qzed]

@shadowrylander You could try to disable bluetooth via rfkill in the systemd sleep script and enable it after wakeup, if nothing else works. You could also have a look at /proc/acpi/wakeup, but I'm not sure if bluetooth is in there at all. The solution by @tmarkov should work though.

[qzed]

@alturismo You can find it here. I'll try to update the builds more frequently in the future.

[shadowrylander]

@tmarkov They seem to be pretty much the same; I found out using the link I posted that it was the bluetooth module that was keeping the system awake, but not why.

@qzed As in my reply above, they seem to be the same help texts; instead, how do I edit the current scripts that control what happens when the lid is opened and closed? I'm thinking of using the rfkill to turn the module on and off, then reconnecting to my devices from the scripts as well.

[alturismo]

@alturismo You can find it here. I'll try to update the builds more frequently in the future.

thanks, sadly same result with no keyboard and also cant replace the module like on 5.1.15 (wrong format) to get it working, so i wait ;)

[tmarkov]

@shadowrylander If so, why don't you just disable wakeup by bluetooth (you can make it survive reboot using systemd)? There shouldn't be any need to turn off the actual bluetooth.

[qzed]

@alturismo

thanks, sadly same result with no keyboard and also cant replace the module like on 5.1.15 (wrong format) to get it working, so i wait ;)

If it works with the module, it should also work with the kernel. For the module to work you will need to completely re-compile it for the kernel you're using (e.g. run make clean all each time you've installed a new kernel).

[qzed]

@shadowrylander as @tmarkov said: Find the bluetooth device (either in /proc/acpi/wakeup or under /sys/bus/...) and disable its wakeup capabilities.

The systemd sleep script (/lib/systemd/system-sleep/sleep) should really be your last option. Also this does trigger when you suspend, it doesn't have to do anything (directly) with the lid (other than lid causing suspend, which causes the script to be run).

[shadowrylander]

@tmarkov I think probably because of this: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1823076 And also because I forgot that was an option. I'll try that.

Also, to @qzed as well, could you tell me which of the entries are for the bluetooth module in /proc/acpi/wakeup, or if it should be clearly labelled bluetooth? I can't seem to find it. And where would it be under /sys/bus/... as well? acpi, for example?

[tmarkov]

Bluetooth is not in /proc/acpi/wakeup. On SB1 it is /sys/bus/pci/devices/0000:00:1d.3/power/wakeup but it may be different on other Surfaces. Honestly your confusion makes little sense to me: you said you found that bluetooth is responsible using this answer https://askubuntu.com/a/1152359, so you clearly must know where in /sys it is, which makes me think we're misunderstanding each other somehow.

[alturismo]

@qzed thanks for the hint

@alturismo

thanks, sadly same result with no keyboard and also cant replace the module like on 5.1.15 (wrong format) to get it working, so i wait ;)

If it works with the module, it should also work with the kernel. For the module to work you will need to completely re-compile it for the kernel you're using (e.g. run make clean all each time you've installed a new kernel).

as its not persistent anyway i ll drop this test now with ubuntu 19.04 and go back to mint, personally best experience with surface laptop here.

https://github.com/jakeday/linux-surface/issues/563#issuecomment-530500845

[shadowrylander]

@tmarkov Huh; I guess it works. I just realized I hadn't actually tested the solution after applying it. Sorry for the confusion; at this rate, no one's going to think my issues are legitimate! :sweat_smile: Thanks again for the help!

[shadowrylander]

Quick note, however: the bluetooth wakeup file re-enables itself when I turn bluetooth back on, which means I would have to disable it again every time I wake the Surface up from suspend. Also, I just realized I never stated my device, which is a Surface Book 2 17". Sorry again!

[tmarkov]

That's true. So you can put the echo disabled > /sys/.../power/wakeup command in the pre) section of /lib/systemd/system-sleep/sleep script so it runs every time before you suspend.

Alternatively, you can setup a systemd service as explained here https://github.com/jakeday/linux-surface/wiki/Frequently-Asked-Questions#my-device-wakes-up-automatically-from-suspendhibernate

[shadowrylander]

Two questions:

1. I'm getting permission errors when trying to redirect echo to the wakeup file, even when using sudo, and
2. I'm assuming the systemd file in the second example runs on every wakeup?

[tmarkov]

1. Yes. Run sudo su and then echo disabled > /sus/.../power/wakeup. It will also run without permission errors from the system-sleep/sleep script or a systemd service.
2. I'm not 100% sure, but I think it would run on every boot. That said, the /power/wakeup values should survive suspend or hibernate, so every boot should be enough.

[qzed]

1. In addition to what @tmarkov wrote: If you want a one-liner: echo disabled | sudo tee /sys/.../power/wakeup or sudo sh -c "echo disabled > /sys/.../power/wakeup" will do the trick. Permissions shouldn't be an issue in the systemd service file or sleep script, so no need to use sudo there.

2. @tmarkov is correct, WantedBy=multi-user.target means it will run at boot. It could be that something like turning bluetooth off and on again changes the wakeup settings (as you've hinted), so you might need to put that into the systemd sleep script. Apart from that, those settings shouldn't change during suspend/resume.

[shadowrylander]

@tmarkov and @qzed: So in the end, should I try the systemd script, then fall back to editing the system-sleep/sleep script if that doesn't work?

[qzed]

Sounds like a good plan

[shadowrylander]

So I tried using the unit file in the systemd example, changing the lid sysfs accordingly, but it didn't seem to work after enabling it and rebooting, i.e. it didn't change the wakeup file contents to disabled. Then I tried changing the wakeup file for just the bluetooth module:

[Unit]
Description=Disable wakeup sources

[Service]
ExecStart=/bin/sh -c 'echo disabled > /sys/bus/usb/devices/1-6/power/wakeup'
Type=oneshot
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

but that didn't work either. I tried running the command under su (from sudo su), and it worked there. Is there anything else I'm missing? Or should I just switch to editing the system-sleep/sleep script?

[tmarkov]

Try systemctl status wakeup.service to make sure it's enabled. If not, run sudo systemctl enable wakeup.service - maybe sudo service enable wakeup doesn't work on newer systems?

If still doesn't work, use the system-sleep/sleep script. Keep in mind this repo overrides it, so if you run the setup.sh you'll need to edit it again.

[shadowrylander]

I started it using sudo systemctl enable wakeup, then checked it's status after reboot; it said it ran just fine (though it doesn't seem to run successfully if Bluetooth wasn't on before restart). I may be forced to use the system-sleep/sleep script at this rate.

[shadowrylander]

UPDATE: I think I'll have to switch to using rfkill to manage bluetooth from the system-sleep/sleep script; disabling the wakeup file didn't work.

[shadowrylander]

UPDATE 2: It would appear as though the system-sleep/sleep script isn't working either; the bluetooth module seems to permanently block suspension. This is what I have right now in the script:

#!/bin/bash
case $1 in
  pre)
    # unload the modules before going to sleep
    systemctl stop NetworkManager.service
    modprobe -r intel_ipts
    modprobe -r mei_me
    modprobe -r mei
    modprobe -r mwifiex_pcie;
    modprobe -r mwifiex;
    modprobe -r cfg80211;
    ####
    rfkill block bluetooth
    ;;
  post)
    # need to cycle the modules on a resume and after the reset is called, so unload...
    modprobe -r intel_ipts
    modprobe -r mei_me
    modprobe -r mei
    modprobe -r mwifiex_pcie;
    modprobe -r mwifiex;
    modprobe -r cfg80211;
    # and reload
    modprobe -i intel_ipts
    modprobe -i mei_me
    modprobe -i mei
    modprobe -i cfg80211;
    modprobe -i mwifiex;
    modprobe -i mwifiex_pcie;
    echo 1 > /sys/bus/pci/rescan
    systemctl restart NetworkManager.service
    ####
    nmcli c up Primus-17FE
    rfkill unblock bluetooth
    echo "connect F0:13:C3:3B:B7:7F" | bluetoothctl
    echo "connect E1:18:19:A6:A9:0B" | bluetoothctl
    ;;
esac

Do I need to add a wait after the rfkill block bluetooth command for it to take effect?

[tmarkov]

I'm pretty sure that /sys/bus/usb/devices/1-6/power/wakeup isn't bluetooth - after all, it's a usb device which bluetooth isn't (on SB1 it's the base) - and that's why rfkill-ing it doesn't help.

Can you confirm that the sleep script is executable?

Did you try disabling all sources but the ones you use rather than only 1-6?

[shadowrylander]

The sleep scipt is indeed executable:

-rwxr-xr-x 1 root root 977 Sep 19 02:37 /lib/systemd/system-sleep/sleep

I searched up the idProduct and idVendor for 1-6 and found this, which is how I determined that it was the bluetooth module. The only other thing with an enabled wakeup script is my Logitech mouse; however, it seemed that my Surface would suspend just fine with that enabled and the bluetooth module disabled, so I thought that it wasn't the issue.

Here is what I get when I run a python script on the xonsh shell to get the devices and wakeup script status' on my shell:

-rw-r--r-- 1 root root 4096 Sep 19 09:58 /sys/bus/usb/devices/1-1.1.3/power/wakeup : enabled
-rw-r--r-- 1 root root 4096 Sep 19 09:58 /sys/bus/usb/devices/1-1.1/power/wakeup : disabled
-rw-r--r-- 1 root root 4096 Sep 19 09:58 /sys/bus/usb/devices/1-1.3/power/wakeup : disabled
-rw-r--r-- 1 root root 4096 Sep 19 09:58 /sys/bus/usb/devices/1-1/power/wakeup : disabled
-rw-r--r-- 1 root root 4096 Sep 19 09:58 /sys/bus/usb/devices/1-6/power/wakeup : disabled
-rw-r--r-- 1 root root 4096 Sep 19 09:58 /sys/bus/usb/devices/1-7/power/wakeup : disabled
-rw-r--r-- 1 root root 4096 Sep 19 09:58 /sys/bus/usb/devices/2-1.1/power/wakeup : disabled
-rw-r--r-- 1 root root 4096 Sep 19 09:58 /sys/bus/usb/devices/2-1/power/wakeup : disabled
-rw-r--r-- 1 root root 4096 Sep 19 09:58 /sys/bus/usb/devices/usb1/power/wakeup : disabled
-rw-r--r-- 1 root root 4096 Sep 19 09:58 /sys/bus/usb/devices/usb2/power/wakeup : disabled

Note that /sys/bus/usb/devices/1-6/power/wakeup becomes enabled when I turn bluetooth on; everything else stays the same. The script I used was this:

for i, j in zip($(ls -l /sys/bus/usb/devices/*/power/wakeup).split("\n"), $(cat /sys/bus/usb/devices/*/power/wakeup).split()):
    print(i, ":", j)

[tmarkov]

Does your suspend work if you manually rfkill bluetooth before suspending?

Not all wakeup files are in /sys/bus/usb/devices/*/power/wakeup, so try this instead: find /sys -name wakeup -printf '%p ' -exec cat {} \;

[shadowrylander]

Yes, rfkill blocking manually beforehand does indeed work. At this rate, is it possible that the bluetooth module activates something else as well that's preventing the Surface from suspending?

[tmarkov]

If it activated something else it would probably do it regardless of whether you rkdill block it manually or with a script... So it's worth looking at what happens differently between manual and script.

Do you remove modules manually before the rfkill? If not, you can try to move the rfkill in the sleep script before the modprobe -r. If that doesn't help, you can try to put a sleep 1 after the rfkill.

[shadowrylander]

Does "removing modules manually" mean in the sleep script, or from the terminal? Because moving rfkill before the modprobe -r commands doesn't seem to be working either:

#!/bin/bash
case $1 in
  pre)
    # unload the modules before going to sleep
    ####
    rfkill block bluetooth
    ####
    systemctl stop NetworkManager.service
    modprobe -r intel_ipts
    modprobe -r mei_me
    modprobe -r mei
    modprobe -r mwifiex_pcie;
    modprobe -r mwifiex;
    modprobe -r cfg80211;
    ;;
  post)
    # need to cycle the modules on a resume and after the reset is called, so unload...
    ####
    rfkill unblock bluetooth
    echo "connect F0:13:C3:3B:B7:7F" | bluetoothctl
    echo "connect E1:18:19:A6:A9:0B" | bluetoothctl
    ####
    modprobe -r intel_ipts
    modprobe -r mei_me
    modprobe -r mei
    modprobe -r mwifiex_pcie;
    modprobe -r mwifiex;
    modprobe -r cfg80211;
    # and reload
    modprobe -i intel_ipts
    modprobe -i mei_me
    modprobe -i mei
    modprobe -i cfg80211;
    modprobe -i mwifiex;
    modprobe -i mwifiex_pcie;
    echo 1 > /sys/bus/pci/rescan
    systemctl restart NetworkManager.service
    ####
    nmcli c up Primus-17FE
    ####
    ;;
esac

[shadowrylander]

UPDATE: It would appear as though merely keeping the bluetooth module on isn't the issue; the connected devices seem to be preventing the Surface from suspending. So should I try disconnecting the devices from the sleep script on suspension, then reconnecting afterwards?

[qzed]

You could give that a try. I'm a bit confused why rfkill doesn't work, with that I'm a bit out of my depth here.

[shadowrylander]

Well, I tried with rfkill, then sleeping for 5, as well as disconnecting from the devices then sleeping for 5, then rfkill and disconnecting then sleeping for 5, but that didn't work either; I know they're not working because my speakers keep reconnecting upon suspending. I'm kind of lost now.

[tmarkov]

Yes, rfkill blocking manually beforehand does indeed work.

Can you re-confirm that and give a step-by-step exactly what you do that works? Sorry if it's tedious asking you to re-confirm, but I have had situations when dealing with suspend problems when something seems to work and later it doesn't any more.

[shadowrylander]

Oh, no problem at all! I just re-confirmed it. I ran rfkill block bluetooth and put the lid down, and the Surface didn't heat up at all, which usually happens when bluetooth devices are still connected while the Surface is being suspended.

For some reason, the post case in the sleep script seems to triggering as right after the pre case, though I'm not sure if this is why suspension isn't happening, or if this is happening because the device isn't suspending.

[tmarkov]

Does't heat up isn't reallu definitive. I usually play a song and see if it restarts on its own.

Also, perhaps there's something in the syslog? Can you give some logs from both cases?

[shadowrylander]

My usual test case is connecting to my speakers before suspending, so when I do so, if the system doesn't suspend, it keeps connecting to my speakers, which keep playing the connected tone. The tone keeps playing repeatedly when turning off bluetooth in the sleep script pre section and turning it on again the post section, which shows that it keeps suspending, but waking up again right afterwards.

Also, where do I get the syslog for this again? I keep forgetting.

[tmarkov]

To get the syslog type journalctl. Please mark the specific sections where you suspend after running rfkill blobk bluetooth and it works; and when you suspend without and it doesn't work. Look for lines containing systemd[1]: Starting Suspend....

[qzed]

@shadowrylander I've just merged a PR (https://github.com/qzed/linux-surface/commit/da7bcd0efc8dfa40ea2f20ef40ec0094986d74f3) from @StollD using bluetoothctl to pretty much the same effect that we want to achieve here with rfkill. Can you, instead of rfkill try bluetoothctl power off and bluetoothctl power on?

[shadowrylander]

@qzed @tmarkov Sorry about that; academics butting in. I'll try it; however, it seems as though the PR won't account for when devices are connected. Does this mean that when devices are connected, bluetooth will not power off?

[qzed]

@shadowrylander

it seems as though the PR won't account for when devices are connected. Does this mean that when devices are connected, bluetooth will not power off?

Yeah, that's right. I think in your case, you should comment out/remove the if clause and just run bluetoothctl power off unconditionally.

[shadowrylander]

Ah, of course. That makes sense.Will do.

In addition, rfkill block bluetooth prevents bluetoothctl power on from working to turn it back on; this is normal, correct?

[qzed]

I think that should be the correct behavior.

[shadowrylander]

My speakers still seem to be connecting repeatedly, meaning the the Surface is constantly waking up; this the current script:

#!/bin/bash
case $1 in
  pre)
    # unload the modules before going to sleep
    ####
    bluetoothctl power off
    ####
    modprobe -r intel_ipts
    modprobe -r mei_me
    modprobe -r mei
    modprobe -r mwifiex_pcie;
    modprobe -r mwifiex;
    modprobe -r cfg80211;
    ;;
  post)
    # need to cycle the modules on a resume and after the reset is called, so unload...
    ####
    bluetoothctl power on
    bluetoothctl connect [MAC Address]
    ####
    modprobe -r mei_me
    modprobe -r mei
    modprobe -r mwifiex_pcie;
    modprobe -r mwifiex;
    modprobe -r cfg80211;
    # and reload
    modprobe -i intel_ipts
    modprobe -i mei_me
    modprobe -i mei
    modprobe -i cfg80211;
    modprobe -i mwifiex;
    modprobe -i mwifiex_pcie;
    echo 1 > /sys/bus/pci/rescan
    systemctl restart NetworkManager.service
    # nmcli c up Primus-17FE
    # sleep 5
    ;;
esac

[alturismo]

may a question, how to check if this script is triggered on suspend/wakeup ?

i actually have the wifi dead or almost dead issue when i use suspend, sometimes i can recall wifi by using the cmd systemctl restart NetworkManager.service mostly not ... so i d like to check if the script is even running on suspend, wakeup ...

Edit, checked with simple echo`s and its running, so thats not the problem it seems.

[qzed]

But if you disable bluetooth before suspending it doesn't wake up? Can you upload a dmesg log of a suspend/resume cycle?

[shadowrylander]

No; as far as I can tell, when devices are connected and I turn it off from the command line, it seems to keep waking up. When devices are not connected and I turn it off from the command line, it doesn't seem to wake up. And when I turn it off from Gnome Settings, it doesn't seem to wake up either.

Also, do you want the logs from when the Bluetooth power off command is in the sleep script, or done manually from the terminal?