Open mbrownnycnyc opened 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.
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.
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.
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.
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.
Correct. I did mean Surface Laptop Gen 1!
@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.
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
@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.
The
low_power_idle_system_residency_us
andslp_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
/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.
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.
@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?
OK. But it's still weird.
package_cstate_show
andslp_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.
@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
@woberts @alexanderi96 About achieving S0ix, let's move to #554 and use this issue just for achieving S3 (traditional suspend-to-ram).
Copy from https://github.com/jakeday/linux-surface/issues/554#issuecomment-531610152
@ 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:
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 withecho $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.