Skip to content
This repository has been archived by the owner on Nov 19, 2024. It is now read-only.

Suspend not working #1

Open
KoKuToru opened this issue Jan 21, 2015 · 21 comments
Open

Suspend not working #1

KoKuToru opened this issue Jan 21, 2015 · 21 comments

Comments

@KoKuToru
Copy link

When doing
systemctl start [email protected]
or
systemctl start yoga-tablet.service.

Suspend stops working, immediately wakes up.

Is there a way to stop the service
when going to suspend and
restart when suspend ends ?

*Suspend by laptop lid close in Gnome 3.14.

@admiralakber
Copy link
Owner

Hey there thanks for the heads up,

I'm assuming you've replaced username with your own username?

You can follow the following to make a script that stops/starts the service pre and post suspend: https://wiki.archlinux.org/index.php/Power_management#Hooks_in_.2Fusr.2Flib.2Fsystemd.2Fsystem-sleep

The script would probably look something like this:

#!/bin/sh
case $1/$2 in
  pre/*)
    echo "Going to $2..."
    systemctl stop yoga-rotate@<YOURUSERNAME>.service
    systemctl stop yoga-tablet.service
    ;;
  post/*)
    echo "Waking up from $2..."
    systemctl start yoga-rotate@<YOURUSERNAME>.service
    systemctl start yoga-tablet.service
    ;;
esac

See how that goes.

@KoKuToru
Copy link
Author

Here is the result:

Jän 21 18:39:40 LucaArch systemd-sleep[13669]: thinkpad-yoga: Going to suspend...
Jän 21 18:39:40 LucaArch systemd-sleep[13669]: ● [email protected] - [ThinkPad Yoga] Rotation with accelerometer
Jän 21 18:39:40 LucaArch systemd-sleep[13669]: Loaded: loaded (/usr/lib/systemd/system/[email protected]; enabled; vendor preset: disabled)
Jän 21 18:39:40 LucaArch systemd-sleep[13669]: Active: inactive (dead) since Mit 2015-01-21 18:39:40 CET; 11ms ago
Jän 21 18:39:40 LucaArch systemd-sleep[13669]: Process: 11601 ExecStart=/usr/bin/env python2 /opt/thinkpad-yoga-scripts/rotate/thinkpad-rotate.py (code=killed, signal=TERM)
Jän 21 18:39:40 LucaArch systemd-sleep[13669]: Main PID: 11601 (code=killed, signal=TERM)
Jän 21 18:39:40 LucaArch systemd-sleep[13669]: ● yoga-tablet.service - [ThinkPad Yoga] Tablet mode
Jän 21 18:39:40 LucaArch systemd-sleep[13669]: Loaded: loaded (/usr/lib/systemd/system/yoga-tablet.service; enabled; vendor preset: disabled)
Jän 21 18:39:40 LucaArch systemd-sleep[13669]: Active: inactive (dead) since Mit 2015-01-21 18:39:40 CET; 9ms ago
Jän 21 18:39:40 LucaArch systemd-sleep[13669]: Process: 11604 ExecStart=/usr/bin/bash /opt/thinkpad-yoga-scripts/tablet/tablet-mode.sh (code=exited, status=0/SUCCESS)
Jän 21 18:39:40 LucaArch systemd-sleep[13669]: Main PID: 11619 (code=killed, signal=TERM)
Jän 21 18:39:40 LucaArch systemd-sleep[13669]: Jän 21 18:38:13 LucaArch su[11613]: (to luca) root on none
Jän 21 18:39:40 LucaArch systemd-sleep[13669]: Suspending system...

It does disable the service, but still wont suspend successful.
Wakes up shortly after.

Adding a sleep

#!/bin/sh
case $1/$2 in
  pre/*)
    echo "thinkpad-yoga: Going to $2..."
    systemctl stop [email protected]
    systemctl stop yoga-tablet.service
    sleep 5
    systemctl status [email protected]
    systemctl status yoga-tablet.service
    ;;
  post/*)
    echo "thinkpad-yoga: Waking up from $2..."
    systemctl start [email protected]
    systemctl start yoga-tablet.service
    systemctl status [email protected]
    systemctl status yoga-tablet.service
    ;;
esac

does magic and works.. but sounds like an ugly hack to me.

@admiralakber
Copy link
Owner

That's interesting - I actually don't have this problem on my Yoga (running KDE 4.14 though) so I can not troubleshoot it myself.

The next step I suppose would be determining whether it is the yoga-rotate or yoga-tablet script which wakes up the computer.

Can you keep yoga-rotate stopped/disabled and yoga-tablet on and see if suspend works as intended?

@KoKuToru
Copy link
Author

I did check this already,
If one of them is started, suspend wont work.

But I will retry/reconfirm, this evening (GMT+1).

@KoKuToru
Copy link
Author

Found the problem.
Reading from the accelerometer aborts the suspend..

Simple test case:

while [ true ]; do
        cat /sys/bus/iio/devices/iio:device1/in_accel_x_raw
        sleep 1
done

My system if it helps:
Distro: ArchLinux
Kernel: Linux LucaArch 3.18.2-2-ARCH #1 SMP PREEMPT Fri Jan 9 07:37:51 CET 2015 x86_64 GNU/Linux
DE: Gnome 3.14.2

Suspending with systemctl suspend

@admiralakber
Copy link
Owner

Hi KoKuToru,

Running your script (all though the accelerometer is in device iio:device4) does not break suspend for me using the same DE and command. I am using the latest Arch Kernel though.

Is this still a problem for you? Do you have the i5 or i7 version of the laptop? By the sounds of it though, disabling the service before suspend may be the simplest solution as you have to read from the accelerometer for natural rotation.

I'll leave this open in case others may have a solution.

Cheers,
Aqeel

@oggy-
Copy link

oggy- commented Mar 24, 2015

I was having the same problem, on an i7 version of the Yoga, using any of the DEs. What seems to have fixed it is to allow the ST_SENSOR_HUB USB device to be suspended. On my machine:

echo auto > /sys/bus/usb/devices/1-1.7/power/control

You can also set this using e.g. powertop (although that doesn't make the setting permanent).

@iRet
Copy link

iRet commented Apr 29, 2015

I have pretty same issue, and unfortunately solution suggestd by @oggy- doesn't work.
If any of 3 service scripts started laptop suspending and then waking up in the next moment.

@iRet
Copy link

iRet commented Apr 29, 2015

Finally found a fancy solution here https://wiki.archlinux.org/index.php/Powertop
I have just created a service file for powertop auto-tune feature and it does the trick.

Hm, played a bit more, it works on first suspend attempt but then, being resumed once, don't want to do it again and even manual running of powertop --auto-tune won't help. Only restart. Sad.

@pfulop
Copy link

pfulop commented May 5, 2015

I have 4.0.1 kernel on ARCH distribution and gnome 3.16. With or without these scripts, the suspend doesn't work. It just wakes up after a second, by examining journalct it happens due to ACPI call.
Also I had no luck with correct behavior any of those script, they are running but do, well, nothing.

@iRet
Copy link

iRet commented May 5, 2015

@pfulop I managed to fix it with metioned above workaround in combination with powertop daemon. The last one might not be required, but I found it useful and keep it.
Here what exact works for me:

cat /usr/lib/systemd/system-sleep/suspend.sh 
#!/bin/sh
case $1/$2 in
  pre/*)
    echo "Going to $2..."
    systemctl stop [email protected]
    systemctl stop [email protected]
    systemctl stop yoga-tablet.service
    sleep 5
    ;;
  post/*)
    echo "Waking up from $2..."
    sleep 5
    systemctl start [email protected]
    systemctl start [email protected]
    systemctl start yoga-tablet.service
    ;;
esac

Finally I faced another issue: laptop won't wake up normally in some cases and getting stuck immediate after sleep but it seems like many of thinkpad laptops suffering from this issue. And disabling usb 3.0 mode in bios is the only fix. Lenovo started to fix this with bios update for some models.

@pfulop
Copy link

pfulop commented May 5, 2015

@iRet Well my problem happens even without these services on my system, it can be clean install. I would say it's more of kernel problem probably not turning off usb devices that has wake allowed?

@iRet
Copy link

iRet commented May 5, 2015

@pfulop Without services it sleeps fine on my side except the problem I mentioned related to usb 3.0. I'm on 4 kernel but latest from 3 branch works the same way. I'm not actually tested on a clean system, usually installing at least tlp immediate after system installation. So this might be the reason. Actually tlp and powertop are must have tools for power saving on intel based laptops.

@pfulop
Copy link

pfulop commented May 5, 2015

@iRet tlp standalone no, but powertop did the trick

@oggy-
Copy link

oggy- commented May 7, 2015

The problem also reappeared on my computer with 4.0 kernels. The following did the trick:

echo “XHC” > /proc/acpi/wakeup

@iRet
Copy link

iRet commented May 8, 2015

@oggy- thanks, that's interesting.
But which particular problem do you mean? with sleep or wake?
Have you ever experienced any problems with waking up after sleep?

@oggy-
Copy link

oggy- commented May 12, 2015

@iRet the problem of not going to sleep (or rather, waking up immediately).

I have also had problems with the system refusing to wake up intermittently, but not recently (I wasn't able to pin down what caused it and whether it was related to the scripts).

@iRet
Copy link

iRet commented May 12, 2015

Finally I found my hangs while waking up was related to 4.0 kernel and 3.16 as well as 3.19 not hangs.
A bit later I did a clean install of Manjaro Kde 0.9 pre 5 with 3.19 kernel out of box (hoping Plasma has a better touch support) and noticed it goes sleep well without hacks on this distro. Weird, but good.

@sibusaman
Copy link

sibusaman commented Nov 5, 2016

Thank you all for this scripts and sharing your experience.

Recently I too installed these scripts in my Thinkpad Yoga 20C0, and I too was facing the problem of suspend not working as expected. As everyone was facing, my system too wakes up immediately after suspending. But the rest of the stuff are working, except for the button to toggle auto-rotate (is it supposed to work?).

I tried to isolate the the cause to one or few of the scripts, and I couldn't, I tried all 16 permutation of the four services/scripts (if anyone is interested in the results please let me know).

Anyway I tried the methods described above to disable the scripts just before suspending and restarting immediately after resuming. I tried the above method as well as implementing the same operation with root-suspend.service and root-resume.service. This was a failure too.
But I noticed one thing, if I disable the root-resume.service (which disables auto-start of the scripts after resume), and suspend the device while still the scripts are running, first time it will fail. But on resuming I noticed that the scripts are not running and if I suspend again, it will work, no issues.
But only till I activate the scripts again, manually. Everytime the script is active the suspend works on the second time.

Another weird thing is that, if I manually stop the scripts and then suspend, it works. But if I write a small shell script for doing them same,

/usr/bin/systemctl stop [email protected]
/usr/bin/systemctl stop [email protected]
/usr/bin/systemctl stop yoga-tablet.service
/usr/bin/systemctl stop yoga-backlight.service
sleep 5
systemctl suspend

It doesn't, Interesting!!.

FInally, I went through the jouralctl logs to find out what wakes the system, and found that an USB XHCI device is the cause. As @oggy- suggested, tried echo “XHC” > /proc/acpi/wakeup, to no success, but then I decided to disable all the USB wakes and it works. No need to disable the scripts anymore.

@pieleric
Copy link

I've got a Lenovo Yoga S1 (20CD), and while not running any script, it would also have similar issues with auto-resume after a few seconds. I'm running a kernel 4.6, with Ubuntu 16.04. It used to work up to Ubuntu 15.10.

I've noticed that echo freeze > /sys/power/state does somehow suspend (but the led doesn't "breath" as in a normal suspend, so maybe it's not reaching a deep state as a real suspend).
However, as echo “XHC” > /proc/acpi/wakeup, does the trick. Now it suspends well again.

@sibusaman
Copy link

sibusaman commented Nov 14, 2016

I have another issue as of now,
I have to keep my fingers moving across the touchpad while booting, otherwise the touchpad won't function. I guess it's going to sleep/suspend and cannot wake up.
It might have to do with what I have done to enable the suspend with the scripts active, or something I have in TLP configuration to minimize the power usage.
The STMicro sensor Hub is talking about 1-2 watts according to the powertop, even after the calibration, anyone reading something like thi?, is this normal?

EDIT:- checking xinput list-prop "SynPS/2 Synaptics TouchPad" I found that the touchpad gets disabled for some reason. This happens when I don't touch the touchpad until the PC completely boots into GUI and sometimes during the resume from sleep too.
The easiest fix I found so far is to run xinput enable "SynPS/2 Synaptics TouchPad" .
I might enable and add this line to root-resume.service till I(or someone else) figure out the reason.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants