[Solved] suspend battery drain on Lenovo 20Y30065US

[juniper]

Hello,

I've got massive battery drain issues while the computer is sleeping.

I came across this ubuntu thread

https://askubuntu.com/questions/1398674 ... in-8-hours

The file /sys/power/mem_sleep exists on my gentoo machine and its only contents are [s2idle]. The trouble is I am not sure what the fix is. Do I edit the file and replace with

[deep]

or

[s2idle] deep

???

[Thistled]

Might not be the right suggestion to offer but....

If you suspend, then a trickle of power is required to keep the data stored in the RAM, in time it will drain the battery.
Therefore I would hibernate (to disk) instead of suspending.
This will save the current state of the OS to disk, and power off the system completely, which in turn will prevent the battery drain.
Last time I looked you state in the kernel config which /dev/sd* you hibernate to.

Hope this helps.

[juniper]

Might not be the right suggestion to offer but....

If you suspend, then a trickle of power is required to keep the data stored in the RAM, in time it will drain the battery.
Therefore I would hibernate (to disk) instead of suspending.
This will save the current state of the OS to disk, and power off the system completely, which in turn will prevent the battery drain.
Last time I looked you state in the kernel config which /dev/sd* you hibernate to.

Hope this helps.

Indeed.

According to that ubuntu post, however, there are different kinds of suspend to ram with s2idle being the most energy intensive and deep being the least. So I am trying to switch to deep, hence my question above.

[pjp]

Holy bonkers interfaces Batman!

Reading the referenced System Sleep States (kernel.org)...

/sys/power/state:
- contains a list of strings representing sleep states supported by the kernel.
- Writing one of these strings into it causes the kernel to start a transition of the system into the sleep state represented by that string.


/sys/power/mem_sleep:
- contains a list of strings representing supported system suspend variants and allows user space to select the variant to be associated with the “mem” string in the state file described above.

- Writing one of the listed strings into this file causes the system suspend variant represented by it to be associated with the “mem” string in the state file. The string representing the suspend variant currently associated with the “mem” string in the state file is listed in square brackets.


To make the system...

Suspend to RAM:
1) write “deep” into /sys/power/mem_sleep , thne
2) write “mem” into /sys/power/state

Suspend to Idle
Method 1:
1) write “freeze” to /sys/power/state

Method 2:
1) write “s2idle” to /sys/power/mem_sleep , then
2) write “mem” to /sys/power/state

Standby (As I interpret the other than clear instructions)
Method 1:
1) write “standby” to /sys/power/state

Method 2:
1) write “shallow” to /sys/power/mem_sleep , then
2) write “mem” to /sys/power/state

Presuming your hardware and kernel support the features / have support enabled.

I've thought about configuring it on my laptop, but haven't yet.

[Thistled]

As per the documentation
https://wiki.gentoo.org/wiki/Suspend_an ... end_to_RAM
are you using s2ram?

[szatox]

On my machine this file contains:
s2idle [deep]


The way those files work is, when you read them they list all the options available and tag the active one, and when you want to activate an option you just write it back to the same file.
You can't activate deep, because it's not listed, which means it's not supported. Most likely you're missing an option in you kernel config

[Thistled]

I like what pjp has to say, and szatox.
You should dig deeper into their advice.
Just out of interest, why not just hibernate?

[Goverp]

Disadvantages of hibernate to suspend include:

• Hibernate doesn't always work all the time due to driver bugs - my hp laptop using amdgpu driver has occasionally been able to hibernate, but usually it just hangs.
• Resuming after hibernate is a lot slower than after suspend, as you are booting the system from cold. You go through BIOS initialization, bootloader (say GRUB), followed by restoring the hibrnated system image, before you get back to a working system. After suspend, it's just the system powering up devices and presenting you with a lock screen to sign in. For my laptop, the former takes maybe 20 seconds, and a GRUB menu choice, whereas the latter is about 1 second...

[Hu]

Beyond the reasons that Goverp listed, getting into hibernate can take much longer than getting into suspend. Entering hibernate requires paging out all the memory that must survive. Suspend keeps all that memory powered, and so is equally fast whether the system is just booted or has completely filled physical memory. For users with an encrypted hibernation image (which is recommended if the system has encrypted persistent storage, and is often required by corporate IT for that reason), restoring requires giving both the disk password and the unlock screen password. For suspend, only the unlock screen password is required on resume.

[logrusx]

Hello,

I've got massive battery drain issues while the computer is sleeping.

I came across this ubuntu thread

https://askubuntu.com/questions/1398674 ... in-8-hours

The file /sys/power/mem_sleep exists on my gentoo machine and its only contents are [s2idle]. The trouble is I am not sure what the fix is. Do I edit the file and replace with

[deep]

or

[s2idle] deep

???

None of the above. You can't "edit" the file. It's not a file as you imagine it. The problem might be kernel support or one of those laptops with the crappy M$ $hit connected standby. What's your exact laptop model?

Best Regards,
Georgi

[juniper]

@pjp: I think I can't do that because my configuration doesn't support it.

Currently /sys/power/state says

Code: Select all

freeze mem disk

and /sys/power/mem_sleep says

Code: Select all

[s2idle]

if I try as root, I get an error

Code: Select all

write:  invalid argument

@georgi: My laptop is Lenovo 20Y30065US. I am having trouble compiling a custom kernel, so I am using gentoo-kernel-bin. Pretty generic I think.

[logrusx]

if I try as root, I get an error

Code: Select all

write:  invalid argument

You can't do that, this is not an ordinary file. If the option is not present when reading, you can't write it. This file is directly related to a device driver. It's a character device.

@georgi: My laptop is Lenovo 20Y30065US. I am having trouble compiling a custom kernel, so I am using gentoo-kernel-bin. Pretty generic I think.

I think you're screwed. Try finding something related in the bios or try downgrading the EFI firmware, but I think Intel stopped implementing this functionality on the chipset level.

State: Suspend-To-Idle
ACPI state: S0
Label: "s2idle" ("freeze")

This state is a generic, pure software, light-weight, system sleep state.
It allows more energy to be saved relative to runtime idle by freezing user
space and putting all I/O devices into low-power states (possibly
lower-power than available at run time), such that the processors can
spend more time in their idle states.

This state can be used for platforms without Power-On Suspend/Suspend-to-RAM
support, or it can be used in addition to Suspend-to-RAM to provide reduced
resume latency. It is always supported.

EDIT: This user's post suggests there is an S3 sleep option in the bios, if you're lucky you'll find it.

Best Regards,
Georgi

[pjp]

@pjp: I think I can't do that because my configuration doesn't support it.

Unfortunately that appears to be true. I believe I've read devices were abandoning "real" power management features so they can remain on with network connectivity.

Per the "Hardware Maintenance Manual" (page 34):

Power management
To reduce power consumption, the computer has three power management modes: screen blank, sleep, and
hibernation.

Sleep mode
When the computer enters sleep mode, the screen goes blank and all internal devices are still powered on
with lower power consumption

Hibernation mode
In hibernation mode, the following occurs:
• The system status, RAM, VRAM, and setup data are stored on the hard disk.
• The system is powered off.

(101 pages) https://download.lenovo.com/pccbbs/mobi ... hmm_en.pdf

[juniper]

EDIT: This user's post suggests there is an S3 sleep option in the bios, if you're lucky you'll find it.

Best Regards,
Georgi

Hey Georgi,

The bios does indeed have two options for sleep state: "Windows and Linux" and "Linux S3". It was on the former before, and I just switched to the latter. Now the contents of /sys/power/mem_sleep are

Code: Select all

s2idle [deep]

I assume that means that deep is the default option. I will test the new sleep state overnight tonight and see how the battery drain goes.

Fingers crossed!

[logrusx]

That should be it. You're lucky.

Best Regards,
Georgi

[juniper]

That should be it. You're lucky.

Best Regards,
Georgi

Appears to work. 8 hours sleep knocked off about 5% of battery life, vs 20%.

And no, it's not luck. It's all skill

I've edited the title for those with the same laptop.

[juniper]

UPDATE:

I can't say I am crazy about the suspend state of this computer. It appears that I lose about 20% over about 28 hours.

dmesg appears to verify that the deep sleep state is achieved (with no errors or issues)

Code: Select all

[64071.428750] elogind-daemon[2029]: Suspending system...
[64071.428760] PM: suspend entry (deep)
[64071.455827] Filesystems sync: 0.027 seconds
[64071.456196] Loading firmware: i915/tgl_dmc_ver2_12.bin
[64071.456279] Loading firmware: iwlwifi-ty-a0-gf-a0-72.ucode
[64071.456353] Loading firmware: iwlwifi-ty-a0-gf-a0.pnvm
[64071.456746] Loading firmware: regulatory.db
[64071.456860] Loading firmware: regulatory.db.p7s
[64071.456884] Loading firmware: intel/sof/sof-tgl-h.ri
[64071.456887] Loading firmware: intel/sof-tplg/sof-hda-generic-2ch.tplg
[64071.458025] Freezing user space processes
[64071.474084] Freezing user space processes completed (elapsed 0.016 seconds)
[64071.474093] OOM killer disabled.
[64071.474096] Freezing remaining freezable tasks
[64071.475456] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[64071.475584] printk: Suspending console(s) (use no_console_suspend to debug)
[64072.882162] PM: suspend devices took 1.407 seconds
[64072.902782] ACPI: EC: interrupt blocked
[64073.237220] ACPI: PM: Preparing to enter system sleep state S3
[64073.255370] ACPI: EC: event blocked
[64073.255372] ACPI: EC: EC stopped
[64073.255373] ACPI: PM: Saving platform NVS memory
[64073.255633] Disabling non-boot CPUs ...
[64073.257350] smpboot: CPU 1 is now offline
[64073.262383] smpboot: CPU 2 is now offline
[64073.266834] smpboot: CPU 3 is now offline
[64073.271466] smpboot: CPU 4 is now offline
[64073.276312] smpboot: CPU 5 is now offline
[64073.281346] smpboot: CPU 6 is now offline
[64073.287073] smpboot: CPU 7 is now offline
[64073.293569] smpboot: CPU 8 is now offline
[64073.299256] smpboot: CPU 9 is now offline
[64073.301305] smpboot: CPU 10 is now offline
[64073.303205] smpboot: CPU 11 is now offline
[64073.305315] smpboot: CPU 12 is now offline
[64073.307438] smpboot: CPU 13 is now offline
[64073.309521] smpboot: CPU 14 is now offline
[64073.311636] smpboot: CPU 15 is now offline
[64073.316373] ACPI: PM: Low-level resume complete
[64073.316443] ACPI: EC: EC started
[64073.316444] ACPI: PM: Restoring platform NVS memory
[64073.317431] Enabling non-boot CPUs ...
[64073.317476] x86: Booting SMP configuration:
[64073.317477] smpboot: Booting Node 0 Processor 1 APIC 0x2
[64073.323802] CPU1 is up
[64073.323830] smpboot: Booting Node 0 Processor 2 APIC 0x4
[64073.327052] CPU2 is up
[64073.327073] smpboot: Booting Node 0 Processor 3 APIC 0x6
[64073.330266] CPU3 is up
[64073.330285] smpboot: Booting Node 0 Processor 4 APIC 0x8
[64073.333485] CPU4 is up
[64073.333505] smpboot: Booting Node 0 Processor 5 APIC 0xa
[64073.336718] CPU5 is up
[64073.336736] smpboot: Booting Node 0 Processor 6 APIC 0xc
[64073.340069] CPU6 is up
[64073.340101] smpboot: Booting Node 0 Processor 7 APIC 0xe
[64073.343517] CPU7 is up
[64073.343536] smpboot: Booting Node 0 Processor 8 APIC 0x1
[64073.345154] CPU8 is up
[64073.345175] smpboot: Booting Node 0 Processor 9 APIC 0x3
[64073.346785] CPU9 is up
[64073.346804] smpboot: Booting Node 0 Processor 10 APIC 0x5
[64073.348376] CPU10 is up
[64073.348395] smpboot: Booting Node 0 Processor 11 APIC 0x7
[64073.350332] CPU11 is up
[64073.350352] smpboot: Booting Node 0 Processor 12 APIC 0x9
[64073.351929] CPU12 is up
[64073.351949] smpboot: Booting Node 0 Processor 13 APIC 0xb
[64073.353540] CPU13 is up
[64073.353559] smpboot: Booting Node 0 Processor 14 APIC 0xd
[64073.355208] CPU14 is up
[64073.355228] smpboot: Booting Node 0 Processor 15 APIC 0xf
[64073.357154] CPU15 is up
[64073.373556] ACPI: PM: Waking up from system sleep state S3
[64073.403764] ACPI: EC: interrupt unblocked
[64073.679298] ACPI: EC: event unblocked
[64073.694433] xhci_hcd 0000:00:0d.0: xHC error in resume, USBSTS 0x401, Reinit
[64073.694440] usb usb1: root hub lost power or was reset
[64073.694442] usb usb2: root hub lost power or was reset
[64073.707388] nvme nvme0: Shutdown timeout set to 10 seconds
[64073.758827] nvme nvme0: 16/0/0 default/read/poll queues
[64073.942251] usb 3-8: reset high-speed USB device number 2 using xhci_hcd
[64074.120739] PM: resume devices took 0.440 seconds
[64074.124451] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops __SCT__tp_func_intel_frontbuffer_flush [i915])
[64074.124817] OOM killer enabled.
[64074.124818] Restarting tasks ...
[64074.124878] mei_pxp 0000:00:16.0-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1: bound 0000:00:02.0 (ops __SCT__tp_func_intel_frontbuffer_flush [i915])
[64074.131147] done.
[64074.131198] random: crng reseeded on system resumption
[64074.447331] PM: suspend exit
[64074.447355] elogind-daemon[2029]: System resumed.

So I think everything is working correctly, it's just that either the linux suspend isn't that great or this particular laptop's hardware isn't great for suspend (my other laptop was more like 12% over 24 hours. It could sleep for a week).

Anyway, I think this is more or less solved.

On an unrelated note, looking at dmesg, is the left-hand string of numbers supposed to be interpreted as a time? how? if not, I think displaying time when these events occur would be useful.

[Hu]

It is time since boot. However, systems which use suspend or hibernate may show misleading data there after resuming. dmesg -T can make it nicer to read, but that too will be misleading after suspend.