You are not logged in.
Hello Guys,
EDIT: I got Hibernate to work using Kernel 5.7 but Suspend is still not working.
I got my HP Envy x360 (ds-0155ng) a few days ago andinstalled Arch on it. However I noticed that I cant use the suspend or hibernate option in kde plasma. I looked a little bit online but cant find a solution to my problem.
It seems like any other state than S0 is not supported:
dmesg | grep -i acpi | grep supports
[ 0.694281] ACPI: (supports S0)
[ 0.713391] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3
Seems like a lot of S states are missing:
➜ ~ cat /sys/power/state
freeze mem disk
➜ ~ cat /sys/power/mem_sleep
[s2idle]
➜ ~
I found this solution but its for an intel cpu and not for an AMD cpu
Does anyody know a solution to this?
My laptop has an AMD Ryzen 5 3500U
Any help is apprechiated
Thank you all in advance
Last edited by Luis-L (2020-06-09 05:12:41)
Offline
Nearly the same for me. Using a HP Envy x360 (13-ay0278ng) with a Ryzen 4700U. No suspend.
dmesg | grep -i acpi | grep supports
[ 0.355449] ACPI: (supports S0 S4 S5)
[ 0.361710] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3]
and
cat /sys/power/state
freeze mem diskcat /sys/power/mem_sleep
[s2idle]
Seems like some acpi DSDT tables are missing?
Offline
The worst part about this is, that HP doesnt seem to care about this issue. I contacted HP about this issue and their support just said something like contact our "Smart" Friends about this issue (Their smart friends cost money, I am not paying for this). I tried some things that are on the Wiki about DSDT but nothing works. I dont think I am buying an HP again. I had more or less the same issue on a ThinkPad and it was fixed by a BIOS update, this is how it should be... HP also doesnt seem to care to keep their website updated. I bought this laptop a few months ago and it came with BIOS/UEFI version F.19. The "newest" version on HPs website is F.18, I am really disappointed in HP
Offline
Sorry for the short bump. I was able to solve this by decompiling, editing and recompiling part of the ACPI tables
run
acpidump -o tables
to create a file with the currently running tables
acpixtract -a tables
to extract the individual tables (we only care about the FACP table)
iasl -d facp.dat
to disassemble the FACP table
edit facp.dsl with your prefered text editor.
set the "Oem Revision" field at the top to a larger number
set the "Hardware Reduced (V5)" field to 0
iasl -sa facp.dsl
to assemble your modified table
Make the following folder structure: payload/kernel/firmware/acpi/
IN the acpi folder add your compiled facp.aml
In the payload folder, run:
find kernel | cpio -H newc --create > acpi_override.cpio.img
Move the resulting acpi_override.cpio.img to your /boot folder, then update grub so your initrd line looks something like this:
initrd /boot/amd-ucode.img /boot/initramfs-linux.img /boot/acpi_override.cpio.img
Also change your Grub CMDLINE to force deep sleep as default for good measure:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=deep"
Hopefully you should then see deep sleep when you run cat /sys/power/mem_sleep.
Offline
Thanks for your reply @jman6495
It sadly doesnt seem to work for me. I did everything as you said but I still cant use suspend or see any other S states. I use systemd-boot instead of grub, here is my config:
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img /amd-ucode.img /acpi_override.cpio.img
options root=UUID=0326b687-33ab-4385-8f0d-6aaf23c79e2d rw mem_sleep_default=deep
Do you see any mistakes there?
Offline
Odd... could you send me the dump of your ACPI tables in full, I'll take a look
Offline
Conclusively, I would say that it is not possible solve this problem.
Microsoft introduces the modern standby, which is called s2idle (suspend to idle) under Linux. Their goal is to totally replace S3 (suspend) with by S0ix (modern standby/s2idle). It seems that M$ is forcing more and more OEM to adopt S0ix, and M$ and OEM are preventing you from using S3 suspend in 2020. Therefore, I guess that while it is possible to echo "mem" > /sys/something/something to enter S3 under Linux, it would be a untested configuration by OEMs.
https://www.dell.com/community/Inspiron … -p/7650768
Sadly, modern standby sucks since the power consumption on most machines are the same as merely turning off the monitor, even on Surface. What's worse, someone can only cold reboot their laptops after suspend.
https://www.thomasmaurer.ch/2018/07/tro … n-standby/
Google s0ix power drain or modern standby power drain, and you can find a lot of people has the same problem (under Windows) after 2019.
Offline
set the "Hardware Reduced (V5)" field to 0
"Hardware Reduced (V5)" is 0 after decompiling the acpi tables.
Any suggestion?
Offline
Hey guys,
I do have the same laptop and dmesg does give me the same output. I'm a little confused tho, as hibernate and suspend worked out of the box on Ubuntu. Why is it on the manufacturer to solve the problem if it works with ubuntu and windows?
Hibernation works fine for me on Arch as well. Suspend (and closing the lid which is the same?) seem to freeze on resume. First time installing Arch and working with Linux in-depth btw. so sorry if it's a stupid question.
Any Idea on how to debug the crash that occurs when I close the lid? The screen gets distorted and after a couple of seconds I can see my desktop but it's frozen. I already tried the ACPI table part but it didn't seem to help me here.
Offline
Hey guys,
I do have the same laptop and dmesg does give me the same output. I'm a little confused tho, as hibernate and suspend worked out of the box on Ubuntu. Why is it on the manufacturer to solve the problem if it works with ubuntu and windows?
Hibernation works fine for me on Arch as well. Suspend (and closing the lid which is the same?) seem to freeze on resume. First time installing Arch and working with Linux in-depth btw. so sorry if it's a stupid question.Any Idea on how to debug the crash that occurs when I close the lid? The screen gets distorted and after a couple of seconds I can see my desktop but it's frozen. I already tried the ACPI table part but it didn't seem to help me here.
See the posting from johnjohnlys. The laptop does suspend to s2idle, but that is not much more than turning the screen black. But the laptop does not go to "deep" suspend state.
Try
cat /sys/power/mem_sleep
Do you get [s2idle][deep] or just [s2idle]?
Offline
Offline
Try
cat /sys/power/mem_sleep
Do you get [s2idle][deep] or just [s2idle]?
I get
[s2idle]
as well. But now I at least understand the problem a little bit better. Thank you!
For now I set closing the lid to hibernate the laptop instead of supending. This avoids the frozen screens I get from suspending at least. Guess I'm gonna try the reddit link from @johnjohnlys next, but this has to wait until after the weekend.
Offline
I'm a little confused tho, as hibernate and suspend worked out of the box on Ubuntu. Why is it on the manufacturer to solve the problem if it works with ubuntu and windows?
What version of ubuntu is suspend working for you under? Perhaps they are achieving s0ix states somehow?
Edit: booted default (unity?) 20.04.1 and saw mixed behavior on a single test. Unscientifically, I saw the same/similar amdgpu crash that I am seeing on arch, but the journal did show a timestamp gap between enter sleep and exit sleep. The screen stayed on, at a blank tty, and otherwise appeared on.
Otherwise, arch is at least turning the screen off (on mainline kernel) and appearing to be off, but sometimes failing to resume seemingly due to amdgpu crash, or otherwise immediately waking per the journal timestamps.
Last edited by sovanyio (2020-08-12 02:55:25)
Offline
What version of ubuntu is suspend working for you under? Perhaps they are achieving s0ix states somehow?
I did test it with 20.04 but I'm now not sure that suspend did indeed work. Closing the lid worked like 80% of the time so I just assumed that the laptop was suspending successfully.
Offline
sovanyio wrote:What version of ubuntu is suspend working for you under? Perhaps they are achieving s0ix states somehow?
I did test it with 20.04 but I'm now not sure that suspend did indeed work. Closing the lid worked like 80% of the time so I just assumed that the laptop was suspending successfully.
I saw the same amdgpu bug until 5.7.8, and suspend (deep sleep) only works at a 20% chance. Now I am on 5.7.11, and with the ACPI fix I posted above, suspend works 20 times without failure.
I haven't tested whether the kernel update or the ACPI revolves the problem, so I would suggest fix the APCI if possible.
Offline
I saw the same amdgpu bug until 5.7.8, and suspend (deep sleep) only works at a 20% chance. Now I am on 5.7.11, and with the ACPI fix I posted above, suspend works 20 times without failure.
I haven't tested whether the kernel update or the ACPI revolves the problem, so I would suggest fix the APCI if possible.
We have two different problems here which get mixed in the thread:
Problem one: no S state (no S3 deep)
Problem two: Notebook doesn't weak up from (s2idle) suspend (screen stays black)
Problem one:
Tried to adapt the ACPI fix above for my HP envy x360 13. Still no S3 deep.
Any suggestions?
Offline
johnjohnlys wrote:I saw the same amdgpu bug until 5.7.8, and suspend (deep sleep) only works at a 20% chance. Now I am on 5.7.11, and with the ACPI fix I posted above, suspend works 20 times without failure.
I haven't tested whether the kernel update or the ACPI revolves the problem, so I would suggest fix the APCI if possible.
We have two different problems here which get mixed in the thread:
Problem one: no S state (no S3 deep)
Problem two: Notebook doesn't weak up from (s2idle) suspend (screen stays black)Problem one:
Tried to adapt the ACPI fix above for my HP envy x360 13. Still no S3 deep.Any suggestions?
I was able to hack the S3 support back via the dsdt mods, but something else appears to be missing. I'm wondering if HP failed to add support for wakeup from S3. I intended to test WOL to see if that would rouse it out of S3, but it has been low on my priority list.
Based on the journal, the system does appear to enter S3, maybe someone who knows dsdt well could hack in wake? /shrug
Edit: WOL did not work to rouse from S3
Last edited by sovanyio (2020-08-17 12:34:05)
Offline
Hey everyone, made an account just for this post, sorry to bump an older thread.
I followed the steps above by jman6495 as well as some steps in this reddit post and finally (after several tries), I managed to get S3 mode enabled on my laptop
Here's the things I changed, in case anyone else would like some steps to try and reproduce on their own Envy x360 (mine is a 15z-ee000 CTD with a Ryzen 4700U):
In facp.dsl:
"Oem Revision" from 00000002 to 00000003
"Hardware Reduced (V5)" was already 0
Changed "Low Power S0 Idle (V5)" from 1 to 0
In dsdt.dsl:
"DefinitionBlock ("", "DSDT", 1, "HPQOEM", "876F ", 0x00000002)" changed to "DefinitionBlock ("", "DSDT", 1, "HPQOEM", "876F ", 0x00000003)" (near the top, one of the first lines)
Pulled this code out from the if statements that contained it (See the reddit thread, this one is ~700 lines in)
Name (_S3, Package (0x04) // _S3_: S3 System State
{
0x03,
0x03,
Zero,
Zero
})
I then recompiled both files by placing them in payload/kernel/firmware/acpi and runnning the following in the payload folder:
find kernel | cpio -H newc --create > acpi_override.cpio.img
Finally, I took the resulting .img file, placed it in my /boot directory, and added these kernel parameters to my boot options
initrd=/acpi_override.cpio.img mem_sleep_default=deep
After booting, I got
$ cat /sys/power/mem_sleep
s2idle [deep]
But as mentioned by sovanyio, I still can't wake the PC during suspend, maybe some other ACPI table changes would help? Anyone have experience with that? Its pretty clear from the journalctl logs that its entering deep sleep as expected, just not resuming.
Offline
Where exactly do I add the initrd line ? Do I do grub-mkconfig?
Offline
Yeah, it would be in your grub config. I use rEFInd, so I put it in my kernel command line parameters in the refind.conf configuration file.
Offline
Hi everyone,
I am monitoring this thread since 1 1/2 year now (purchase date of my hp envy x360 convertible 13-ar0xxx) and all tries getting suspend mode to work failed.
Happily theres light at the end of tunnel when looking forward the 5.11 kernel which introduces s2idle support for ryzen mobile architecture:
https://www.phoronix.com/scan.php?page= … Linux-5.11
Currently being a windows slowpoke but can't wait to try it out.
Offline
Upgrading to kernel 5.11 fixed the inability to wake from s2idle on my HP Pavilion 15z-eh000 Ryzen 4700U.
Offline
I followed the steps above by jman6495 as well as some steps in this reddit post and finally (after several tries), I managed to get S3 mode enabled on my laptop
But as mentioned by sovanyio, I still can't wake the PC during suspend, maybe some other ACPI table changes would help? Anyone have experience with that? Its pretty clear from the journalctl logs that its entering deep sleep as expected, just not resuming.
Hi, I have the same problem. I followed the steps you have described, which got S3 mode enabled for my laptop too. And like you, now I can't wake up my laptop after suspend.
Have you managed to solve this problem?
Offline
Hey,
So I was managed to workaround this issue with fully working S2IDLE (suspend), but without hibernation I just followed n00bs guide here and it worked.
Basically it's just applying patches renoir-suspend-patches-hp-envy-x360.tar.xz to your kernel. But remember to quirk patch your nvme.
And voila, suspend works just fine on my hp envy x360 13-ay009ne. Battery usage during suspend is good, same for resume timing.
Two disadvantages is broken hibernation and that it works only on kernel v5.12.0-rc2.
cheers
Last edited by dee (2021-04-14 17:33:33)
Offline
Hello everyone,
I got S3 working on my hp envy 15-ds1083-cl finally thanks to a ton of trial and error and the info in this thread. Here's what I did in case it helps anyone (including myself if I ever reinstall haha)!
I essentially followed the steps from jman6495, and Gadgethm, with the following differences due to issues decompiling/compiling the acpi tables
# tmp folder for working
mkdir acpi
# acquire the acpi tables from the kernel
cp -R /sys/firmware/acpi/tables acpi
# put only the aml files we want in another folder to work with
cd acpi/tables
mkdir aml
for i in SSDT*; do cp $i aml/$i.aml; done
cp DSDT aml/DSDT.aml
# disassemble
# After MUCH trial and error and googling various problems I FINALLY found the only possible combination of external includes that would get DSDT to disassemble was the following:
iasl -e SSDT11.aml SSDT12.aml SSDT1.aml SSDT16.aml -d DSDT.aml
# FACP just worked
iasl FACP.aml
I then changed the following just as Gadgethm in FACP.dsl:
"Oem Revision" from 00000002 to 00000003
"Hardware Reduced (V5)" was already 0
Changed "Low Power S0 Idle (V5)" from 1 to 0
In DSDT.dsl I also incremented the revision here just as Gadgethm:
DefinitionBlock ("", "DSDT", 2, "HPQOEM", "87A9 ", 0x01072010)
Further in DSDT.dsl there was no such _S3 related stuff anywhere to be found, the original relevant section looked like this:
Name (_S0, Package (0x04) // _S0_: S0 System State
{
Zero,
Zero,
Zero,
Zero
})
Name (XS3, Package (0x04)
{
0x03,
Zero,
Zero,
Zero
})
Name (_S4, Package (0x04) // _S4_: S4 System State
{
0x04,
Zero,
Zero,
Zero
})
Name (_S5, Package (0x04) // _S5_: S5 System State
{
0x05,
Zero,
Zero,
Zero
})
So I simply added the following block after the _S0 block:
Name (_S3, Package (0x04) // _S3_: S3 System State
{
0x03,
0x03,
Zero,
Zero
})
I then of course was UNABLE to compile the DSDT.dsl due to compiler errors that were not related to anything I had changed... I eventually decided to just remove the offending lines to resolve the errors... I don't know if they were necessary or not but nothing has exploded yet so I think it's okay! ymmv... Here is a diff showing the lines I removed:
+++ mod2/DSDT.dsl 2021-05-28 10:54:58.611156660 -0600
@@ -8998,24 +8998,6 @@
DerefOf (Local0 [0x02]) [0x0E] = Zero
DerefOf (Local0 [0x02]) [0x0F] = Zero
}
- Case (0x03)
- {
- DerefOf (Local0 [0x02]) [One] = Zero
- DerefOf (Local0 [0x02]) [0x02] = Zero
- DerefOf (Local0 [0x02]) [0x03] = Zero
- DerefOf (Local0 [0x02]) [0x04] = Zero
- DerefOf (Local0 [0x02]) [0x05] = Zero
- DerefOf (Local0 [0x02]) [0x06] = Zero
- DerefOf (Local0 [0x02]) [0x07] = Zero
- DerefOf (Local0 [0x02]) [0x08] = Zero
- DerefOf (Local0 [0x02]) [0x09] = Zero
- DerefOf (Local0 [0x02]) [0x0A] = Zero
- DerefOf (Local0 [0x02]) [0x0B] = Zero
- DerefOf (Local0 [0x02]) [0x0C] = Zero
- DerefOf (Local0 [0x02]) [0x0D] = Zero
- DerefOf (Local0 [0x02]) [0x0E] = Zero
- DerefOf (Local0 [0x02]) [0x0F] = Zero
- }
Default
{
}
@@ -12874,17 +12856,6 @@
}
}
- Scope (_SB)
- {
- Method (SWSI, 4, NotSerialized)
- {
- ^PCI0.GPP4.XPDV.RWSI.RWSY [Zero] = (Arg0 & 0xFF)
- ^PCI0.GPP4.XPDV.RWSI.RWSY [One] = (Arg1 & 0xFF)
- ^PCI0.GPP4.XPDV.RWSI.RWSY [0x02] = (Arg2 & 0xFF)
- ^PCI0.GPP4.XPDV.RWSI.RWSY [0x03] = (Arg3 & 0xFF)
- }
- }
-
Scope (_SB)
{
Device (WFDE)
At last with these changes I was able to successfully compile the dsl files, created the initrd (following jman6495's instructions), and added it to my grub.cfg, and viola!
I now have
# cat /sys/power/mem_sleep
s2idle [deep]
And it successfully suspends and resumes!
I think this is officially the most annoying obstacle i have EVER come across in my 15+ years of using linux... Thanks HP and microsuck...
Hope this helps someone!
Last edited by nasaiya (2021-05-28 17:42:40)
Offline