[SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

esonn · 2018-04-11 20:14:21

Have you re-generated your GRUB config file since changing /etc/default/grub? You can verify by calling

sudo cat /boot/grub/grub.cfg | grep deep

and looking whether mem_deep_sleep is shown. Or if the currently booted kernel has the option set via

$ cat /proc/cmdline

rin · 2018-04-11 21:25:09

esonn wrote:

Have you re-generated your GRUB config file since changing /etc/default/grub? You can verify by calling
sudo cat /boot/grub/grub.cfg | grep deep
and looking whether mem_deep_sleep is shown. Or if the currently booted kernel has the option set via
$ cat /proc/cmdline

Yep, regenerating it has fixed it.
Thank you!

axboe · 2018-04-27 14:18:04

For what it's worth, BIOS 1.15 still doesn't show S3 out of the box. I updated yesterday and used the below patch to get it to work.

https://pastebin.com/VDBTJDmP

h54 · 2018-04-28 01:02:24

axboe wrote:

For what it's worth, BIOS 1.15 still doesn't show S3 out of the box. I updated yesterday and used the below patch to get it to work.
https://pastebin.com/VDBTJDmP

What are you patching and how is applied?

axboe · 2018-04-28 01:05:36

h54 wrote:

axboe wrote:
For what it's worth, BIOS 1.15 still doesn't show S3 out of the box. I updated yesterday and used the below patch to get it to work.
https://pastebin.com/VDBTJDmP

What are you patching and how is applied?

It's referenced earlier in this thread, basically the decompiled ACPI tables. See: https://delta-xi.net/#056

PastExcitement · 2018-04-29 19:24:16

I successfully applied the original X1C6_S3_DSDT.patch and manually removed the two "One" lines to make S3 work with the 1.15 BIOS.

mrfaber · 2018-05-01 07:39:37

For me, even in S3 deep sleep with patched DSDT tables, BIOS 1.15 there's about 0.6W 0.3W power usage during sleep.
(Edit: Measured again on a longer time horizon, now getting around 0.3W which is considerably better but still not optimal)

I've disabled the fingerprint reader, SD-card-reader and the USB always-on charge ports in BIOS.
Do you get the same Watt draw?

This is how I've measured:

Log current energy with service files on suspend and resume, needs upower

#/etc/systemd/system/log-energy-suspend.service
[Unit]
Description=Log energy level on suspend
Before=suspend.target

[Service]
Type=simple
# Need to refresh UPower state since by default it only measures every 120 seconds or so
ExecStartPre=/usr/bin/dbus-send --system --dest=org.freedesktop.UPower --type=method_call /org/freedesktop/UPower/devices/battery_BAT0 org.freedesktop.UPower.Device.Refresh
ExecStart=/bin/bash -c 'upower -i $(upower -e | grep BAT0) | grep "energy:" | awk \'{print $(NF-1)}\''

[Install]
WantedBy=suspend.target

#/etc/systemd/system/log-energy-resume.service
[Unit]
Description=Log energy level on resume
After=suspend.target

[Service]
Type=simple
ExecStartPre=/usr/bin/dbus-send --system --dest=org.freedesktop.UPower --type=method_call /org/freedesktop/UPower/devices/battery_BAT0 org.freedesktop.UPower.Device.Refresh
ExecStart=/bin/bash -c 'upower -i $(upower -e | grep BAT0) | grep "energy:" | awk \'{print $(NF-1)}\''

[Install]
WantedBy=suspend.target

Install into /etc/systemd/system and then run

systemctl daemon-reload
systemclt enable log-energy-{suspend,resume}.service

Suspend, wait a bit, then evaluate energy usage with this script:

suspend_msg=$(journalctl --no-pager -o short-unix -u log-energy-suspend.service | tail -n 1)
resume_msg=$(journalctl --no-pager -o short-unix -u log-energy-resume.service | tail -n 1)
suspend_ts=$(echo $suspend_msg | awk '{print $1}')
resume_ts=$(echo $resume_msg | awk '{print $1}')
suspend_energy=$(echo $suspend_msg | awk '{print $NF}')
resume_energy=$(echo $resume_msg | awk '{print $NF}')
if [ $LC_NUMERIC == "de_DE.UTF-8" ]
then
    # Fix decibel separator
    # In some locales the decibel separator is a comma instead of a dot
    # E.g energy is given in 30,4 Wh instead of 30.4 Wh
    suspend_energy=$(echo $suspend_energy | sed 's/,/\./')
    resume_energy=$(echo $resume_energy | sed 's/,/\./')
fi
energy_used=$(echo "scale=5; "$suspend_energy" - "$resume_energy | bc) # in Wh
time_in_suspend=$(echo "scale=5; "$resume_ts" - "$suspend_ts | bc) # in seconds
echo Used $energy_used Wh
echo Slept for $time_in_suspend seconds
time_in_suspend_hours=$(echo "scale=8; "$time_in_suspend" / 3600" | bc)
rate_during_suspend=$(echo "scale=10; "$energy_used" / "$time_in_suspend_hours | bc)
echo Rate during suspend: $rate_during_suspend W

(One could also use bare sysfs variables instead of upower like this:

ExecStart=/bin/bash -c "echo $(cat /sys/class/power_supply/BAT0/energy_now)"

But not every laptop supplies energy_now in sysfs. Some only report charge_now,
which theoretically could be combined with voltage_min_design to get energy_now
But anyway, upower is probably more accurate.)

Last edited by mrfaber (2018-05-02 03:40:16)

bookymonster · 2018-05-24 10:12:37

The link in the pinned message is broken, i.e. the fix that has worked for me in the past but now I've updated versions so I need to redo.

http://delta-xi.net/#056

Does anybody have a non broken link?

progandy · 2018-05-24 10:55:32

Change the link to with https, then it should work
https://delta-xi.net/#056

bookymonster · 2018-05-24 11:25:29

thanks!

h54 · 2018-06-10 05:59:53

Looks like another BIOS version (1.22). Anyone try it? I plan to in the morning.

axboe · 2018-06-10 16:54:45

h54 wrote:

Looks like another BIOS version (1.22). Anyone try it? I plan to in the morning.

Installed it the other day - no change in ACPI tables, still needs the same procedure to enable S3. Works fine for me after that.

sixbay · 2018-06-11 18:48:28

UPDATE: (tl; dr: no issue to be resolved; ignore post unless you want to be glad you're not 'that guy')

After substantial googling, it seemed that the troubleshooting order of operations is: 1) connect to an external display to rule out graphics card issues; 2) disconnect the main battery, wait, then reconnect and power on; 3) disconnect the CMOS battery, wait, then reconnect and power on.

I tried each of these steps, but they did not fix the issue. I took the laptop into a repair shop for a second opinion. They repeated the same steps, which still did not fix the issue. The consensus is that the motherboard is toasted.

I have initiated the repair process through Lenovo, so we'll see how that goes. However, if anyone has insight as to why this might have happened, I'd like to hear it. I'm curious why such a seemingly benign change to the BIOS settings ("seemingly", to someone of my experience level) would have such decidedly not-benign consequences.

###########

New user here, so please bear with me. I'm also stuck using a phone browser for reasons that I will describe shortly.

I decided not to make a new topic since my issue is directly related to the deep sleep patch, but I am happy to start one if you all think it's appropriate. I've searched the forum for topics that appear to be related, but have found none (or maybe I'm not using the right keywords).

For context, I am using an X1 Yoga Gen 3 and my last `pacman -Syu` was early last week.

I read https://wiki.archlinux.org/index.php/Le … on_(Gen_6) and followed that article to this forum topic, which I then followed to https://delta-xi.net/#056 . In that last link it was stated that the patch process had been confirmed for the X1 Yoga G3. That being the case, I decided to follow the guide.

I executed the first step (boot into UEFI/BIOS, set Thunderbolt BIOS assist mode 'enabled'; set Secure boot 'disabled'). I saved and exited. The screen stayed black for ~3 minutes, at which point I tried Ctrl + Alt + F#s to see if I could make anything at all happen, but no luck. After another couple minutes, I unforgivingly powered down the machine. On reboot, the power comes on (the keyboard illuminates briefly, and the 'Esc' and 'F1' LEDs come on), but I cannot access the BIOS. I receive no prompts to the screen -- it stays black (but the backlight comes on).

So I've done something extremely stupid, and I could really use your collective help to fix it.

I really do appreciate your patience and assistance. Going to chalk this one up as a learning experience...

Last edited by sixbay (2018-06-11 23:51:05)

clews · 2018-06-12 16:58:24

sixbay wrote:

I executed the first step (boot into UEFI/BIOS, set Thunderbolt BIOS assist mode 'enabled'; set Secure boot 'disabled'). I saved and exited. The screen stayed black for ~3 minutes, at which point I tried Ctrl + Alt + F#s to see if I could make anything at all happen, but no luck. After another couple minutes, I unforgivingly powered down the machine. On reboot, the power comes on (the keyboard illuminates briefly, and the 'Esc' and 'F1' LEDs come on), but I cannot access the BIOS. I receive no prompts to the screen -- it stays black (but the backlight comes on).
So I've done something extremely stupid, and I could really use your collective help to fix it.
I really do appreciate your patience and assistance. Going to chalk this one up as a learning experience...

I had quite the same problem (screen-light turn on, keyboard responsive but nothing else. As far as I remember the change of TB setting worked for me, so perhaps it is not directly related). Don't think that you did something stupid, or at least you're not alone ;-)... Seems to be a problem with this new machine...

With on-site guarantee, Lenovo came by two times, changed twice the mainboard. The first try brought back the BIOS but the machine was unable to boot anything (Stick, NVMe). The technician supposed that the new MB is the problem. I proposed to the second technician that came a few days later to leave out all components and try to start up this way. It turned out, that the WWAN-Card (Fibocom L850-GL) prevented the boot process... For now, I have a new MB and a working X1Y3 without the WWAN card (not a problem, as it does not work with linux for now)... Not completely satisfied with this rather expensive product... New WWAN-Card is announced for mid-july... We'll see how things will go on...

Last edited by clews (2018-06-12 16:59:46)

zez · 2018-06-24 21:08:21

I just finished setting this up on an X1C6 (BIOS 1.22) using the instructions and patch at https://delta-xi.net/#056. There were a couple small surprises, so I'm going to document it here.

Surprise #1: The current version of iasl in acpica (20180531-2) segfaults when compiling.

This seems like some upstream issue. I was able to get around it by manually installing an old version of iasl-20180531-2 from https://archive.archlinux.org/packages/i/iasl/. Sidenote, there were almost no old versions of the acpica package, so I assume the iasl package was renamed to acpica recently.

Surprise #2: Hunk 7 of the patch failed on my DSDT file.

I think the delta-xi post sort of called this issue out, but I was able to fix it by modifying the patch file. Hunk 7 of the patch had the following line:

     OperationRegion (GNVS, SystemMemory, 0xAB54E000, 0x0767)

In my copy of dsdt.dsl arguments 3 and 4 had diferent hex values. I changed that line of the patch to match and it started working. These values probably vary, but for reference this is what I changed it to:

     OperationRegion (GNVS, SystemMemory, 0x4FF4E000, 0x0771)

Surprise #3: Turns out you can also automate the custom initrd line in /etc/default/grub

I hate having config files break after upgrading kernels, so I was determined to get this one working. Version 1 was hacking /etc/grub.d/10_linux to automatically include the acpi_override.img file in the initrd line. This did work, but after thinking about it a bit I realized that the environment variables controlling everything (GRUB_EARLY_INITRD_LINUX_STOCK and GRUB_EARLY_INITRD_LINUX_CUSTOM) can probably just be set in /etc/default/grub.

TLDR; Add the following line to /etc/default/grub and the initrd config will be setup for you automatically by grub-mkconfig:

GRUB_EARLY_INITRD_LINUX_CUSTOM="acpi_override.img"

NOTE: For consistency I named my file "acpi_override.img" instead of "acpi_override" like the delta-xi post. Just use whatever filename you used in /boot.

nottinhill · 2018-06-25 00:11:47

@zez Could you shed some more details on your persistent solution regading grub? I tried your steps and it did not enable S3. Doing it the way from delta-xi blog, it worked for me.

In addition I'm on Bios 1.23 and the patch did segfault for me. I tried compiling an older iasl without success (hitting some cryptic bugs when doing make install), therefore I edited the decompiled dsl file by hand entirely according to this excellent post: https://corrupted.io/2018/06/06/X1C6G-S … eeBSD.html and got it to work. I have now working S3 Suspend on Kernel 4.14.

zez · 2018-06-25 05:49:42

nottinhill wrote:

@zez Could you shed some more details on your persistent solution regading grub? I tried your steps and it did not enable S3. Doing it the way from delta-xi blog, it worked for me.
In addition I'm on Bios 1.23 and the patch did segfault for me. I tried compiling an older iasl without success (hitting some cryptic bugs when doing make install), therefore I edited the decompiled dsl file by hand entirely according to this excellent post: https://corrupted.io/2018/06/06/X1C6G-S … eeBSD.html and got it to work. I have now working S3 Suspend on Kernel 4.14.

What I posted takes the place of step 9 in the delta-xi post. You still need to do step 10 which also has you add a different line to /etc/default/grub. You should be able to verify that it is working both in the grub-mkconfig output and manually if you open up your grub.cfb file and inspect the initrd line.

The thing I tried to point out is that I used a slightly different filename, so if you followed the delta-xi steps exactly you should use "acpi_override" as the value in GRUB_EARLY_INITRD_LINUX_CUSTOM. This filename then has to exist in your boot partition (/boot/acpi_override) or grub will silently skip it and not put it into the initrd line.

Beyond that I'm not sure what else might be an issue. If you feel comfortable you could try experimenting with setting that GRUB_EARLY_INITRD_LINUX_CUSTOM variable directly in /etc/grub.d/10_linux. That was the original way I had it working.

piehei · 2018-06-25 17:14:40

Those of you who have got S3 deep sleep working, did you do *any* fixes/changes/custom settings/whatnot for the touchpad & trackpad buttons?

Following the delta-xi instructions I get deep sleep working (though it still consumes 0.5 W/h) but the touchpad, trackpad buttons, and trackpoint become completely unreliable. They might or might not work after resume. Some goes for booting up the system. Sometimes modprobing helps, sometimes not.

Do you have *any* custom mouse settings or *just* the S3 fixes á la delta-xi? Thanks a lot!

(I have to note that I'm not running Arch but Ubuntu 18.04 with kernel version 4.17.2. Not sure if that should make any difference.)

axboe · 2018-06-25 19:21:28

I've cut down the patch to something that is JUST what it needs be. This means you're not screwing around with things you should not be, and it also means that it applies in a straight forward manner going forward in BIOS revisions. I've put it here, I'd encourage folks to use that instead of the bigger/older versions.

http://kernel.dk/acpi.patch

Last edited by axboe (2018-06-25 22:13:09)

piehei · 2018-06-26 16:59:53

axboe wrote:

I've cut down the patch to something that is JUST what it needs be. This means you're not screwing around with things you should not be, and it also means that it applies in a straight forward manner going forward in BIOS revisions. I've put it here, I'd encourage folks to use that instead of the bigger/older versions.
http://kernel.dk/acpi.patch

Hmm. With this patch I get 64 errors and 334 warnings from running iasl -ve -tc dsdt.dsl. Most of the errors seem to be of type "Name already exists in scope".

axboe · 2018-06-26 17:07:18

piehei wrote:

axboe wrote:
I've cut down the patch to something that is JUST what it needs be. This means you're not screwing around with things you should not be, and it also means that it applies in a straight forward manner going forward in BIOS revisions. I've put it here, I'd encourage folks to use that instead of the bigger/older versions.
http://kernel.dk/acpi.patch
Hmm. With this patch I get 64 errors and 334 warnings from running iasl -ve -tc dsdt.dsl. Most of the errors seem to be of type "Name already exists in scope".

I think you're using a version of iasl that's too old.

Edit: just checked, and I'm using:

ASL+ Optimizing Compiler/Disassembler version 20180313

that I downloaded and built myself, as the one that came with my distro was too old.

Last edited by axboe (2018-06-26 17:12:05)

piehei · 2018-06-27 09:20:59

axboe wrote:

piehei wrote:
axboe wrote:
I've cut down the patch to something that is JUST what it needs be. This means you're not screwing around with things you should not be, and it also means that it applies in a straight forward manner going forward in BIOS revisions. I've put it here, I'd encourage folks to use that instead of the bigger/older versions.
http://kernel.dk/acpi.patch
Hmm. With this patch I get 64 errors and 334 warnings from running iasl -ve -tc dsdt.dsl. Most of the errors seem to be of type "Name already exists in scope".
I think you're using a version of iasl that's too old.
Edit: just checked, and I'm using:
ASL+ Optimizing Compiler/Disassembler version 20180313
that I downloaded and built myself, as the one that came with my distro was too old.

You are absolutely correct. Got the latest version and it mostly works on my machine.

1.
Memory regions @ 421 were different -> removing of "One"s had to be done manually.

2.
The output of iasl -d produced this:

13825 \_SB.SGOV (DerefOf (Arg0 [0x02]), (DerefOf (Arg0 [0x03]) ^
13826 0x01))

with which iasl -ve -tc dsdt.dsl wasn't too happy and aborted in error. Fixing that by hand to

13825 \_SB.SGOV (DerefOf (Arg0 [0x02]), (DerefOf (Arg0 [0x03]) ^ 0x01))

was enough and compilation with iasl worked just fine.

nasigoreng · 2018-06-29 06:02:28

Thanks Everyone! You are all awesome!

I followed the delta-xi post and the most recent instructions here and have S3 working on my X1C.
Used the rEFInd bootloader just adding acpi_override to the kernel parameters.

axboe · 2018-07-02 16:11:51

piehei wrote:

axboe wrote:
piehei wrote:
Hmm. With this patch I get 64 errors and 334 warnings from running iasl -ve -tc dsdt.dsl. Most of the errors seem to be of type "Name already exists in scope".
I think you're using a version of iasl that's too old.
Edit: just checked, and I'm using:
ASL+ Optimizing Compiler/Disassembler version 20180313
that I downloaded and built myself, as the one that came with my distro was too old.
You are absolutely correct. Got the latest version and it mostly works on my machine.
1.
Memory regions @ 421 were different -> removing of "One"s had to be done manually.
2.
The output of iasl -d produced this:
13825 \_SB.SGOV (DerefOf (Arg0 [0x02]), (DerefOf (Arg0 [0x03]) ^
13826 0x01))
with which iasl -ve -tc dsdt.dsl wasn't too happy and aborted in error. Fixing that by hand to
13825 \_SB.SGOV (DerefOf (Arg0 [0x02]), (DerefOf (Arg0 [0x03]) ^ 0x01))
was enough and compilation with iasl worked just fine.

The initial application may be a bit more tricky, the point of my version was to boil it down to the bare minimum. That makes the initial application easier, and subsequent ones should apply without rejects, making further BIOS updates trivial. Case in point, just upgraded to 1.25, and the acpi table image generation is now just fully automated for me and takes just a minute of time after booting with the new bios.

piou · 2018-07-08 08:50:31

piehei wrote:

Those of you who have got S3 deep sleep working, did you do *any* fixes/changes/custom settings/whatnot for the touchpad & trackpad buttons?

Did you, or anyone else, manage to fix that?

I also got S3 to work, only issue I have now is that the touchpad and the buttons don't work after suspending.

I tried pretty much every fix I could find but none worked for me yet.

Arch Linux

#76 2018-04-11 20:14:21

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#77 2018-04-11 21:25:09

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#78 2018-04-27 14:18:04

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#79 2018-04-28 01:02:24

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#80 2018-04-28 01:05:36

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#81 2018-04-29 19:24:16

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#82 2018-05-01 07:39:37

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#83 2018-05-24 10:12:37

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#84 2018-05-24 10:55:32

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#85 2018-05-24 11:25:29

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#86 2018-06-10 05:59:53

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#87 2018-06-10 16:54:45

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#88 2018-06-11 18:48:28

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#89 2018-06-12 16:58:24

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#90 2018-06-24 21:08:21

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#91 2018-06-25 00:11:47

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#92 2018-06-25 05:49:42

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#93 2018-06-25 17:14:40

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#94 2018-06-25 19:21:28

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#95 2018-06-26 16:59:53

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#96 2018-06-26 17:07:18

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#97 2018-06-27 09:20:59

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#98 2018-06-29 06:02:28

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#99 2018-07-02 16:11:51

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

#100 2018-07-08 08:50:31

Re: [SOLVED] Lenovo X1C6 / X1Y3 (2018): No deep sleep (S3)?

Board footer