admiralakber / thinkpad-yoga-scripts

Thinkpad Yoga S1 scripts for GNU/Linux
http://blog.admiralakber.com/?p=400
GNU General Public License v3.0
147 stars 31 forks source link

Suspend not working #1

Open KoKuToru opened 9 years ago

KoKuToru commented 9 years ago

When doing systemctl start yoga-rotate@username.service 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 commented 9 years ago

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 commented 9 years ago

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]: ● yoga-rotate@luca.service - [ThinkPad Yoga] Rotation with accelerometer
Jän 21 18:39:40 LucaArch systemd-sleep[13669]: Loaded: loaded (/usr/lib/systemd/system/yoga-rotate@.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; 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 yoga-rotate@luca.service
    systemctl stop yoga-tablet.service
    sleep 5
    systemctl status yoga-rotate@luca.service
    systemctl status yoga-tablet.service
    ;;
  post/*)
    echo "thinkpad-yoga: Waking up from $2..."
    systemctl start yoga-rotate@luca.service
    systemctl start yoga-tablet.service
    systemctl status yoga-rotate@luca.service
    systemctl status yoga-tablet.service
    ;;
esac

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

admiralakber commented 9 years ago

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 commented 9 years ago

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

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

KoKuToru commented 9 years ago

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 commented 9 years ago

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- commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

@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 wacom-proximity@artyom.service
    systemctl stop yoga-rotate@artyom.service
    systemctl stop yoga-tablet.service
    sleep 5
    ;;
  post/*)
    echo "Waking up from $2..."
    sleep 5
    systemctl start wacom-proximity@artyom.service
    systemctl start yoga-rotate@artyom.service
    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 commented 9 years ago

@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 commented 9 years ago

@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 commented 9 years ago

@iRet tlp standalone no, but powertop did the trick

oggy- commented 9 years ago

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

echo “XHC” > /proc/acpi/wakeup
iRet commented 9 years ago

@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- commented 9 years ago

@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 commented 9 years ago

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 commented 7 years ago

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 wacom-proximity@sibu.service
/usr/bin/systemctl stop yoga-rotate@sibu.service
/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 commented 7 years ago

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 commented 7 years ago

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.