jakeday / linux-surface

Linux Kernel for Surface Devices
2.59k stars 241 forks source link

Acheiving s3 suspend-to-ram? #571

Open mbrownnycnyc opened 5 years ago

mbrownnycnyc commented 5 years ago

I'm attempting to configure suspend-to-ram on pop!-os (ubuntu 1804) and am running into issues.

I had questions about using cryptswap and my power state options, which I resolved quite easily by reading this to gain an understand which states I could enter most easily. I desire suspend-to-RAM, and this appears to be the thing I can do with cryptswap without some more gymnastics. Great, no problem.

I then started reading this and this which explained that I should review the contents of /sys/power/state to see which states are achievable by sending the specific state with echo $state > /sys/power/state.

I also read that the mem state is sort of arbitrary and described within /sys/power/mem_sleep. the contents of this file on my system are [s2idle]. This is not my desired state as it achieves freeze, when I wish to achieve suspend-to-ram (s3).

Is this an issue with the kernel?

I have a Surface Book Gen 1.

kitakar5525 commented 5 years ago

I've just written about adding ACPI S3 state by patching DSDT table for SB1 on another issue (https://github.com/jakeday/linux-surface/issues/554#issuecomment-531610152), which is still broken though.

Most Surface series have the ACPI S3 state disabled and there is no way to enable S3 officially (there is no such option to enable S3 sleep in UEFI).

Is this an issue with the kernel?

So, the kernel is not relevant to this issue in that there is no option to use S3 sleep.

mbrownnycnyc commented 5 years ago

Thank you for the response.

What state does Windows 10 achieve and how can it be achieved with jakeday's? I noticed s2idle is okay, but definitely consumes much more power than I'm used to hybrid sleep on Windows 10.

If suspend-to-hibernate/hybrid sleep is the best option, I will have to do more work as I have a cryptswap; not a problem, just requires some additional leg work.

kitakar5525 commented 5 years ago

What state does Windows 10 achieve

Surface series on Windows 10 uses Modern Standby (S0ix states), not S3.

how can it be achieved with jakeday's?

On s2idle, when all preconditions are met, the S0ix states will be achieved. However, it seems to be some conditions are not met for SB1 and SP4. The biggest problem is, we are not sure what exactly the preconditions are. By the way, some SB2 owners reported their device can achieve S0ix states with v5.2 patches (not merged into jakeday repo yet). There are also releases for prebuild kernel.

On my SB1 with Linux 5.2 and the v5.2 patches, the battery consumption on s2idle is about less than 2 %/h. I feel it's not so bad for me.

mbrownnycnyc commented 5 years ago

May I ask if this problem exists on Surface Notebook Gen 1? I may end up buying one shortly.

Thank you again for the reply and all of your work. I see you are highly impactful with fixes and troubleshooting with this project.

I look forward to any additional work to achieve S0ix states.

kitakar5525 commented 5 years ago

Surface Notebook Gen 1

You mean Surface Laptop Gen 1? I've not yet heard any news from SL1 owner. So, I'm not sure. Honestly, I'm curious too, especially on SP5/SP6.

Thank you again for the reply and all of your work.

hehehe. Thank you.

mbrownnycnyc commented 5 years ago

Correct. I did mean Surface Laptop Gen 1!

qzed commented 5 years ago

@mbrownnycnyc I'd assume that the newer devices work fine with s2idle/S0ix (it's generally my impression that the newer hardware is a bit more stable), but as @kitakar5525 mentioned, we don't have any definitive reports on this. You could ask on gitter about this, maybe someone there can give you a better answer.

alexanderi96 commented 5 years ago

Honestly, I'm curious too, especially on SP5/SP6.

Hi, I've got a SP5. I'm gonna test it right now. If it works I'll toss windows away right away

kitakar5525 commented 5 years ago

@alexanderi96 Thank you for testing on SP5!

You can check if your device had been entered S0ix states. To do so, run this script after suspend (a 10 sec suspend is enough):

# Get CPU model (script from neofetch)
awk -F '\\s*: | @' \
'/model name|Hardware|Processor|^cpu model|chip type|^cpu type/ {
cpu=$2; if ($1 == "Hardware") exit } END { print cpu }' "/proc/cpuinfo"; \
\
cat /etc/os-release | grep NAME; \
echo -n "uname -r: "; uname -r; \
sudo grep -H . /sys/devices/virtual/dmi/id/product_name; \
sudo grep -H . /sys/devices/virtual/dmi/id/product_sku; \
sudo grep -H . /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us; \
sudo grep -H . /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us; \
sudo grep -H . /sys/kernel/debug/pmc_core/package_cstate_show; \
sudo grep -H . /sys/kernel/debug/pmc_core/slp_s0_residency_usec; \
sudo grep -H . /sys/kernel/debug/pmc_atom/sleep_state; \
sudo grep -H . /sys/kernel/debug/telemetry/s0ix_residency_usec

The low_power_idle_system_residency_us and slp_s0_residency_usec counters will be increased if S0ix was achieved.

alexanderi96 commented 5 years ago

The low_power_idle_system_residency_us and slp_s0_residency_usec counters will be increased if S0ix was achieved.

Intel(R) Core(TM) i5-7300U CPU NAME="PopLOS" PRETTY_NAME="Pop!_OS 19.04" VERSION_CODENAME=disco UBUNTU_CODENAME=disco uname -r: 5.2.15-surface /sys/devices/virtual/dmi/id/product_name:Surface Pro /sys/devices/virtual/dmi/id/product_sku:Surface_Pro_1796 /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us:64372942 /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us:0 grep: /sys/kernel/debug/pmc_core/package_cstate_show: File o directory non esistente grep: /sys/kernel/debug/pmc_core/slp_sO_residency_usec: File o directory non esistente grep: /sys/kernel/debug/pmc_atom/sleep_state: File o directory non esistente grep: /sys/kernel/debug/telemetry/sOix_residency_usec: File o directory non esistente

This is the result of your script. I was able to only get the low_idle_cpu_residency_us counter to increase, the low_power_idle_system_residency_us counter is 0 and it is unable to locate the other files as well unfortunately.

Mine is a fresh pop_os install, so I didn't swapped hybernate with suspend, I only installed the new 5.2 patched kernel from qzed

kitakar5525 commented 5 years ago

/sys/kernel/debug/pmc_core/slp_sO_residency_usec: File o directory non esistente grep:

Maybe you misspelled? It's not O but 0 (zero). You can simply copy and paste it into your terminal.

the low_power_idle_system_residency_us counter is 0

Have you run setup.sh? If not, try it or simply unload wifi modules before suspend:

modprobe -r mwifiex_pcie
modprobe -r mwifiex
modprobe -r cfg80211

To get wifi working after suspend:

modprobe cfg80211
modprobe mwifiex
modprobe mwifiex_pcie

Unfortunately, it seems that wifi modules (mwifiex) prevent S0ix on some devices.

alexanderi96 commented 5 years ago

Maybe you misspelled? It's not O but 0 (zero). You can simply copy and paste it into your terminal.

no, the script is correct, i just used an ocr to extract the text from a screenshot because after the test the wifi was not working anymore and i had to reboot.

Have you run setup.sh? If not, try it or simply unload wifi modules before suspend:

Yes I have. Before testing suspend again I tried to disable the wifi module, but as I wrote modprobe -r cfg80211 it told me immediately that it was unable to remove it because the module was in use. I tried to suspend anyway but the result was exactly the same as before. At least the wifi started to work without any problem with the last 3 modprobe commands.

kitakar5525 commented 5 years ago

@alexanderi96

i just used an ocr

OK. But it's still weird. package_cstate_show and slp_s0_residency_usec should exist.

Before testing suspend again I tried to disable the wifi module, but as I wrote modprobe -r cfg80211 it told me immediately that it was unable to remove it because the module was in use.

Actually, I think we don't need to unload the cfg80211 module (I just copied it from system-sleep/sleep script)

If unloading mwifiex_pcie and mwifiex did not work for S0ix, I have no idea for now.

Do you see a suspicious output from dmesg -x log after suspend?

StollD commented 5 years ago

OK. But it's still weird. package_cstate_show and slp_s0_residency_usec should exist.

It doesn't show because qzed's debian kernel is not compiled with CONFIG_INTEL_PMC_CORE enabled.

https://github.com/qzed/linux-surface-kernel-configs/blob/v5.2/debian-5.2-x86_64.config#L7326


@alexanderi96

You could try disabling bluetooth in the BIOS. Enabling bluetooth completely breaks S0ix for me on SB2. Since SB2 and SP5 have the same CPU, it might work for you too.

Also make sure that you are using the sleep script from qzed's repository, not the one from here.

woberts commented 5 years ago

@kitakar5525 with thanks to @StollD for the Fedora scripts I ran the script with Fedora 30 on my SP5 and got similar results to alexanderi96, no s0ix...

Intel(R) Core(TM) i5-7300U CPU NAME=Fedora VERSION_CODENAME="" PRETTY_NAME="Fedora 30 (Workstation Edition)" CPE_NAME="cpe:/o:fedoraproject:fedora:30" uname -r: 5.2.16-surface /sys/devices/virtual/dmi/id/product_name:Surface Pro /sys/devices/virtual/dmi/id/product_sku:Surface_Pro_1796 /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us:2777648193 /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us:0 /sys/kernel/debug/pmc_core/package_cstate_show:Package C2 : 0x42e933ba2fe /sys/kernel/debug/pmc_core/package_cstate_show:Package C3 : 0xb50416fc /sys/kernel/debug/pmc_core/package_cstate_show:Package C6 : 0x124b6bac /sys/kernel/debug/pmc_core/package_cstate_show:Package C7 : 0x15a79a3 /sys/kernel/debug/pmc_core/package_cstate_show:Package C8 : 0x68b435aa /sys/kernel/debug/pmc_core/package_cstate_show:Package C9 : 0x251f121 /sys/kernel/debug/pmc_core/package_cstate_show:Package C10 : 0x49f5c738abe7 /sys/kernel/debug/pmc_core/slp_s0_residency_usec:0 grep: /sys/kernel/debug/pmc_atom/sleep_state: No such file or directory grep: /sys/kernel/debug/telemetry/s0ix_residency_usec: No such file or directory

kitakar5525 commented 5 years ago

@woberts @alexanderi96 About achieving S0ix, let's move to #554 and use this issue just for achieving S3 (traditional suspend-to-ram).

kitakar5525 commented 5 years ago

Copy from https://github.com/jakeday/linux-surface/issues/554#issuecomment-531610152


Enabling ACPI S3 (traditional suspend-to-ram) (broken on SB1)

@ Surface owners

By the way, if we are lucky, adding ACPI S3 (traditional suspend-to-ram) support is not so difficult by patching DSDT. For SB1, you just need to change one line to notify the Linux kernel that this device does support S3 state:

diff --git a/dsdt.dsl b/dsdt.dsl
index 1d520ff..259de4f 100644
--- a/dsdt.dsl
+++ b/dsdt.dsl
@@ -185,7 +185,7 @@ DefinitionBlock ("", "DSDT", 2, "MSFT  ", "MSFT    ", 0x00000001)

     Name (SS1, Zero)
     Name (SS2, Zero)
-    Name (SS3, Zero)
+    Name (SS3, One)
     Name (SS4, One)
     OperationRegion (GNVS, SystemMemory, 0x8BEB6000, 0x077C)
     Field (GNVS, AnyAcc, Lock, Preserve)

Refer to ArchWiki for compiling DSDT.

Then, tell the Linux kernel to prefer S3 state for suspend:

echo deep | sudo tee /sys/power/mem_sleep

However, my SB1 cannot wakeup from S3 sleep. So, I tried with ASPM disabled according to the finding on previous comment (add pcie_aspm=off to your bootloader) but it has no effect.

References for adding S3 by patching DSDT on another devices: