Created attachment 290333 [details] acpidump The laptop is unable to resume after entering deep sleep (s3). Pressing the power button to resume turns on the laptop (I can hear the fans) but the screen doesn't turn on, the lights from the keyboard stay off too. I added the kernel parameter `acpi_sleep=s3_beep` but there is no sound/beep. I have to push the power button to turn off the computer, and push it once again to start it. At this point the laptop start normally with all the previous state lost. Note that resume from s2idle works correctly. Let me know if you need any more informations. This is on ClearLinux with kernel 5.7.8
Created attachment 290335 [details] dmesg after a normal boot
Created attachment 290337 [details] lspci
Created attachment 290339 [details] dmidecode
Created attachment 290341 [details] journal -k when entering deep sleep
Could you please help try to narrow down by testing different mode of /sys/power/pm_test? And to figure out at which stage it fails. Please refer to https://www.kernel.org/doc/html/latest/power/basic-pm-debugging.html?highlight=pm_test for how to use this mode. thanks, Chenyu
I'm not sure if it's the same issue, but the XPS 13 9300 also fails to resume from deep sleep out of the box. There is a "known" workaround (reported for example on reddit [1]) which works for me: disabling the "Signs of Life" options in the bios. The options disable showing the dell logo and activating the keyboard backlight on resume. When I try to resume without the workaround enabled I see the dell logo for a second or two, it then hangs with a corrupted image on the screen in place of the dell logo. I then have to power off by holding the power button. Tested with "5.8.0-050800-generic" (ubuntu mainline) [1] https://www.reddit.com/r/archlinux/comments/fvyyry/installing_arch_on_dell_xps_9300_2020/fmn6ufz/
(In reply to David Hedberg from comment #6) > I'm not sure if it's the same issue, but the XPS 13 9300 also fails to > resume from deep sleep out of the box. > > There is a "known" workaround (reported for example on reddit [1]) which > works for me: disabling the "Signs of Life" options in the bios. The options > disable showing the dell logo and activating the keyboard backlight on > resume. > > When I try to resume without the workaround enabled I see the dell logo for > a second or two, it then hangs with a corrupted image on the screen in place > of the dell logo. I then have to power off by holding the power button. > > Tested with "5.8.0-050800-generic" (ubuntu mainline) > > [1] > https://www.reddit.com/r/archlinux/comments/fvyyry/ > installing_arch_on_dell_xps_9300_2020/fmn6ufz/ This is not working with 9500 or at least with fedora 32 5.7.15-200.fc32.x86_64 and the symptoms are a bit different no corrupted screen - it just hangs on the logo (or no logo if signs of life are disabled) and only cold reboot brings it back.
(In reply to Chen Yu from comment #5) > Could you please help try to narrow down by testing different mode of > /sys/power/pm_test? > And to figure out at which stage it fails. > > Please refer to > https://www.kernel.org/doc/html/latest/power/basic-pm-debugging. > html?highlight=pm_test > for how to use this mode. > > thanks, > Chenyu I followed the docs. 1. echo deep > /sys/power/mem_sleep then 2. echo (freezer|devices|platform|processors|core) > /sys/power/pm_test and 3. echo mem > /sys/power/state after each of tests from 2) after each of them the system was comming back cleanly with no indications of problems in /sys/kernel/debug/suspend_stats This is the content after "echo core > /sys/power/pm_test" [root@thais ~]# cat /sys/kernel/debug/suspend_stats success: 2 fail: 0 failed_freeze: 0 failed_prepare: 0 failed_suspend: 0 failed_suspend_late: 0 failed_suspend_noirq: 0 failed_resume: 0 failed_resume_early: 0 failed_resume_noirq: 0 failures: last_failed_dev: last_failed_errno: 0 0 last_failed_step: Still after real suspend it is not coming up. The unit has the latest BIOS available - 1.3.1 I can provide more info or asyst with the troubleshooting if it is needed.
(In reply to kostadin.karaivanov from comment #8) > (In reply to Chen Yu from comment #5) > > Could you please help try to narrow down by testing different mode of > > /sys/power/pm_test? > > And to figure out at which stage it fails. > > > > Please refer to > > https://www.kernel.org/doc/html/latest/power/basic-pm-debugging. > > html?highlight=pm_test > > for how to use this mode. > > > > thanks, > > Chenyu > I followed the docs. > 1. echo deep > /sys/power/mem_sleep > then > 2. echo (freezer|devices|platform|processors|core) > /sys/power/pm_test > and > 3. echo mem > /sys/power/state > after each of tests from 2) after each of them the system was comming back > cleanly with no indications of problems in /sys/kernel/debug/suspend_stats > > > Still after real suspend it is not coming up. > The unit has the latest BIOS available - 1.3.1 > > I can provide more info or asyst with the troubleshooting if it is needed. Thanks for testing. It looks like on this platform it does not support S3, it is possible that Dell is switching from S3 to S0ix(by running s2idle) which does not involve ACPI S3. Just wonder if S3 ever worked on this platform in older kernel previously?
Well, XPS 15 9500 was released June 2020 so my tests are as old as fedora 32 which was latest at the time. I've tried the above tests in one form or another with every kernel fedora got updated with up till now fedora 33 with latest kernel 5.8.something. In the mean time at least two BIOS upgrades were applied w/o changing the system in this regard so I don't know if this ever worked or worse is it supposed to work at all. For sure there is BIOS option along the lines "force S3 suspend" which changes nothing. There are anecdotal claims in reddit (https://www.reddit.com/r/linuxhardware/comments/guhz5f/xps_15_9500_s3_deep_sleep_not_working/) that at least XPS 17 9700 can be made to work with s3 but the proposed workarounds are not working with 9500 and I'm not sure how similar 9700 and 9500 are.
(In reply to kostadin.karaivanov from comment #10) > Well, XPS 15 9500 was released June 2020 so my tests are as old as fedora 32 > which was latest at the time. > > I've tried the above tests in one form or another with every kernel fedora > got updated with up till now fedora 33 with latest kernel 5.8.something. > > In the mean time at least two BIOS upgrades were applied w/o changing the > system in this regard so I don't know if this ever worked or worse is it > supposed to work at all. > > For sure there is BIOS option along the lines "force S3 suspend" which > changes nothing. > > There are anecdotal claims in reddit > (https://www.reddit.com/r/linuxhardware/comments/guhz5f/ > xps_15_9500_s3_deep_sleep_not_working/) that at least XPS 17 9700 can be > made to work with s3 but the proposed workarounds are not working with 9500 > and I'm not sure how similar 9700 and 9500 are. How about rtcwake -m mem -s 30? If it still does not work, I would expect this platform does not have solid S3 support as it seems that the CPU did not even jump back from BIOS during resume(fan is on while lights are off and no beep via `acpi_sleep=s3_beep`) If this is the case, do you prefer using s2idle for your daily use?
(In reply to Chen Yu from comment #11) > (In reply to kostadin.karaivanov from comment #10) > > Well, XPS 15 9500 was released June 2020 so my tests are as old as fedora > 32 > > which was latest at the time. > > > > I've tried the above tests in one form or another with every kernel fedora > > got updated with up till now fedora 33 with latest kernel 5.8.something. > > > > In the mean time at least two BIOS upgrades were applied w/o changing the > > system in this regard so I don't know if this ever worked or worse is it > > supposed to work at all. > > > > For sure there is BIOS option along the lines "force S3 suspend" which > > changes nothing. > > > > There are anecdotal claims in reddit > > (https://www.reddit.com/r/linuxhardware/comments/guhz5f/ > > xps_15_9500_s3_deep_sleep_not_working/) that at least XPS 17 9700 can be > > made to work with s3 but the proposed workarounds are not working with 9500 > > and I'm not sure how similar 9700 and 9500 are. > How about rtcwake -m mem -s 30? > If it still does not work, I would expect this platform does not have solid > S3 support as it seems that the CPU did not even jump back from BIOS during > resume(fan is on while lights are off and no beep via `acpi_sleep=s3_beep`) > If this is the case, do you prefer using s2idle for your daily use? 'rtcwake -m mem -s 30' after 'echo deep > /sys/power/mem_sleep' still does not work. However fans are on and Dell logo is on the screen. Have not tested with acpi_sleep=s3_beep kernel param. Not sure if it is related but on boot I see these lines in dmesg: [ 38.929697] pci 0000:01:00.0: can't change power state from D3cold to D0 (config space inaccessible) [ 40.288103] rfkill: input handler disabled [ 40.591656] pci 0000:01:00.0: can't change power state from D3cold to D0 (config space inaccessible) [ 40.591985] pci 0000:01:00.0: can't change power state from D3cold to D0 (config space inaccessible) [ 47.671267] pci 0000:01:00.0: can't change power state from D3cold to D0 (config space inaccessible) [ 47.671714] pci 0000:01:00.0: can't change power state from D3cold to D0 (config space inaccessible) There is slight difference between the attached lspci and mine as I have no Xeon but i7-10750H CPU The main reason I'm after S3 and not s2idle is that the latter drains my battery in a day or two
> 'rtcwake -m mem -s 30' after 'echo deep > /sys/power/mem_sleep' still does > not work. However fans are on and Dell logo is on the screen. Have not > tested with acpi_sleep=s3_beep kernel param. > > Not sure if it is related but on boot I see these lines in dmesg: > > [ 38.929697] pci 0000:01:00.0: can't change power state from D3cold to D0 > (config space inaccessible) > [ 40.288103] rfkill: input handler disabled > [ 40.591656] pci 0000:01:00.0: can't change power state from D3cold to D0 > (config space inaccessible) > [ 40.591985] pci 0000:01:00.0: can't change power state from D3cold to D0 > (config space inaccessible) > [ 47.671267] pci 0000:01:00.0: can't change power state from D3cold to D0 > (config space inaccessible) > [ 47.671714] pci 0000:01:00.0: can't change power state from D3cold to D0 > (config space inaccessible) > > There is slight difference between the attached lspci and mine as I have no > Xeon but i7-10750H CPU > > The main reason I'm after S3 and not s2idle is that the latter drains my > battery in a day or two acpi_sleep=s3_beep produces no sound on attempted resume.
(In reply to kostadin.karaivanov from comment #12) > (In reply to Chen Yu from comment #11) > > (In reply to kostadin.karaivanov from comment #10) > > > Well, XPS 15 9500 was released June 2020 so my tests are as old as fedora > > 32 > > > which was latest at the time. > > > > > > I've tried the above tests in one form or another with every kernel > fedora > > > got updated with up till now fedora 33 with latest kernel 5.8.something. > > > > > > In the mean time at least two BIOS upgrades were applied w/o changing the > > > system in this regard so I don't know if this ever worked or worse is it > > > supposed to work at all. > > > > > > For sure there is BIOS option along the lines "force S3 suspend" which > > > changes nothing. > > > > > > There are anecdotal claims in reddit > > > (https://www.reddit.com/r/linuxhardware/comments/guhz5f/ > > > xps_15_9500_s3_deep_sleep_not_working/) that at least XPS 17 9700 can be > > > made to work with s3 but the proposed workarounds are not working with > 9500 > > > and I'm not sure how similar 9700 and 9500 are. > > How about rtcwake -m mem -s 30? > > If it still does not work, I would expect this platform does not have solid > > S3 support as it seems that the CPU did not even jump back from BIOS during > > resume(fan is on while lights are off and no beep via `acpi_sleep=s3_beep`) > > If this is the case, do you prefer using s2idle for your daily use? > > 'rtcwake -m mem -s 30' after 'echo deep > /sys/power/mem_sleep' still does > not work. However fans are on and Dell logo is on the screen. Have not > tested with acpi_sleep=s3_beep kernel param. > > Not sure if it is related but on boot I see these lines in dmesg: > > [ 38.929697] pci 0000:01:00.0: can't change power state from D3cold to D0 > (config space inaccessible) > [ 40.288103] rfkill: input handler disabled > [ 40.591656] pci 0000:01:00.0: can't change power state from D3cold to D0 > (config space inaccessible) > [ 40.591985] pci 0000:01:00.0: can't change power state from D3cold to D0 > (config space inaccessible) > [ 47.671267] pci 0000:01:00.0: can't change power state from D3cold to D0 > (config space inaccessible) > [ 47.671714] pci 0000:01:00.0: can't change power state from D3cold to D0 > (config space inaccessible) > > There is slight difference between the attached lspci and mine as I have no > Xeon but i7-10750H CPU > > The main reason I'm after S3 and not s2idle is that the latter drains my > battery in a day or two So the failing device is 01:00.0 3D controller: NVIDIA Corporation Device 1f95 (rev a1). How about disable the graphic card and see if it is better?
(In reply to Chen Yu from comment #14) > (In reply to kostadin.karaivanov from comment #12) > > (In reply to Chen Yu from comment #11) > > > (In reply to kostadin.karaivanov from comment #10) > > > > Well, XPS 15 9500 was released June 2020 so my tests are as old as > fedora > > > 32 > > > > which was latest at the time. > > > > > > > > I've tried the above tests in one form or another with every kernel > > fedora > > > > got updated with up till now fedora 33 with latest kernel > 5.8.something. > > > > > > > > In the mean time at least two BIOS upgrades were applied w/o changing > the > > > > system in this regard so I don't know if this ever worked or worse is > it > > > > supposed to work at all. > > > > > > > > For sure there is BIOS option along the lines "force S3 suspend" which > > > > changes nothing. > > > > > > > > There are anecdotal claims in reddit > > > > (https://www.reddit.com/r/linuxhardware/comments/guhz5f/ > > > > xps_15_9500_s3_deep_sleep_not_working/) that at least XPS 17 9700 can > be > > > > made to work with s3 but the proposed workarounds are not working with > > 9500 > > > > and I'm not sure how similar 9700 and 9500 are. > > > How about rtcwake -m mem -s 30? > > > If it still does not work, I would expect this platform does not have > solid > > > S3 support as it seems that the CPU did not even jump back from BIOS > during > > > resume(fan is on while lights are off and no beep via > `acpi_sleep=s3_beep`) > > > If this is the case, do you prefer using s2idle for your daily use? > > > > 'rtcwake -m mem -s 30' after 'echo deep > /sys/power/mem_sleep' still does > > not work. However fans are on and Dell logo is on the screen. Have not > > tested with acpi_sleep=s3_beep kernel param. > > > > Not sure if it is related but on boot I see these lines in dmesg: > > > > [ 38.929697] pci 0000:01:00.0: can't change power state from D3cold to D0 > > (config space inaccessible) > > [ 40.288103] rfkill: input handler disabled > > [ 40.591656] pci 0000:01:00.0: can't change power state from D3cold to D0 > > (config space inaccessible) > > [ 40.591985] pci 0000:01:00.0: can't change power state from D3cold to D0 > > (config space inaccessible) > > [ 47.671267] pci 0000:01:00.0: can't change power state from D3cold to D0 > > (config space inaccessible) > > [ 47.671714] pci 0000:01:00.0: can't change power state from D3cold to D0 > > (config space inaccessible) > > > > There is slight difference between the attached lspci and mine as I have no > > Xeon but i7-10750H CPU > > > > The main reason I'm after S3 and not s2idle is that the latter drains my > > battery in a day or two > > So the failing device is 01:00.0 3D controller: NVIDIA Corporation Device > 1f95 (rev a1). How about disable the graphic card and see if it is better? Indeed it is but the device has no such a BIOS option.The tests I did were with no NVIDIA drivers (proprietary or nouveau) loaded.
https://lore.kernel.org/patchwork/patch/1185564/ To get rid of the nvidia device in OS, above patch might help. Could you apply it and boot up with pci.blacklist_dev=xxx:yyyy to blacklist the nvidia device and try s3 again? thanks.
(In reply to Chen Yu from comment #16) > https://lore.kernel.org/patchwork/patch/1185564/ > > To get rid of the nvidia device in OS, above patch might help. > Could you apply it and boot up with pci.blacklist_dev=xxx:yyyy to > blacklist the nvidia device and try s3 again? thanks. with the recent kernels 5.12.xx (perhaps even with 5.11) I cannot find "can't change power state from D3cold to D0 (config space inaccessible)" in dmesg any longer. here is what it says now: [ 0.458582] pci 0000:01:00.0: [10de:1f95] type 00 class 0x030200 [ 0.458601] pci 0000:01:00.0: reg 0x10: [mem 0xb3000000-0xb3ffffff] [ 0.458617] pci 0000:01:00.0: reg 0x14: [mem 0x70000000-0x7fffffff 64bit pref] [ 0.458632] pci 0000:01:00.0: reg 0x1c: [mem 0x80000000-0x81ffffff 64bit pref] [ 0.458641] pci 0000:01:00.0: reg 0x24: [io 0x3000-0x307f] [ 0.458650] pci 0000:01:00.0: reg 0x30: [mem 0xfff80000-0xffffffff pref] [ 0.458734] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold I tried your patch. It does not apply cleanly to 5.12. The first hunk was rejected so I removed it(it touches some documentation so I assume that's fine ). The rest applies against 5.12.8 with some offsets. Even with kernel cmdline including "pci.blacklist_dev=10de:1f95" taken from: $ lspci -nn |grep NVI 01:00.0 3D controller [0302]: NVIDIA Corporation TU117M [GeForce GTX 1650 Ti Mobile] [10de:1f95] (rev a1) I can still see NVIDIA in lspci output And resume from S3 is still not working. BTW am I expected to see message like "PCI: Unknown option blacklist_dev" if I boot with the above cmdline option and kernel w/o the patch? If so I cannot see such a message. example below with 5.12.7 w/o the patch $ cat /proc/cmdline BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.12.7-300.fc34.x86_64 root=/dev/mapper/main-root ro resume=/dev/mapper/main-swap rd.luks.uuid=luks-ca71ce03-d4a0-4341-afef-17c3933d6815 rd.lvm.lv=main/root rd.lvm.lv=main/swap mitigations=off rhgb quiet rd.driver.blacklist=nouveau modprobe.blacklist=nouveau pci.blacklist_dev=10de:1f95 $ dmesg |grep option $
(In reply to kostadin.karaivanov from comment #17) > (In reply to Chen Yu from comment #16) > > https://lore.kernel.org/patchwork/patch/1185564/ > > > > To get rid of the nvidia device in OS, above patch might help. > > Could you apply it and boot up with pci.blacklist_dev=xxx:yyyy to > > blacklist the nvidia device and try s3 again? thanks. > > with the recent kernels 5.12.xx (perhaps even with 5.11) I cannot find > "can't change power state from D3cold to D0 (config space inaccessible)" in > dmesg any longer. > > here is what it says now: > [ 0.458582] pci 0000:01:00.0: [10de:1f95] type 00 class 0x030200 > [ 0.458601] pci 0000:01:00.0: reg 0x10: [mem 0xb3000000-0xb3ffffff] > [ 0.458617] pci 0000:01:00.0: reg 0x14: [mem 0x70000000-0x7fffffff 64bit > pref] > [ 0.458632] pci 0000:01:00.0: reg 0x1c: [mem 0x80000000-0x81ffffff 64bit > pref] > [ 0.458641] pci 0000:01:00.0: reg 0x24: [io 0x3000-0x307f] > [ 0.458650] pci 0000:01:00.0: reg 0x30: [mem 0xfff80000-0xffffffff pref] > [ 0.458734] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold > > If there is no warning message about the D-state transaction, then there is no need to disable the graphic card anymore. > > I tried your patch. It does not apply cleanly to 5.12. > The first hunk was rejected so I removed it(it touches some documentation so > I assume that's fine ). The rest applies against 5.12.8 with some offsets. > > Even with kernel cmdline including "pci.blacklist_dev=10de:1f95" > > taken from: > $ lspci -nn |grep NVI > 01:00.0 3D controller [0302]: NVIDIA Corporation TU117M [GeForce GTX 1650 Ti > Mobile] [10de:1f95] (rev a1) > > I can still see NVIDIA in lspci output > And resume from S3 is still not working. > > BTW am I expected to see message like "PCI: Unknown option blacklist_dev" if > I boot with the above cmdline option and kernel w/o the patch? > If so I cannot see such a message. > example below with 5.12.7 w/o the patch > > $ cat /proc/cmdline > BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.12.7-300.fc34.x86_64 > root=/dev/mapper/main-root ro resume=/dev/mapper/main-swap > rd.luks.uuid=luks-ca71ce03-d4a0-4341-afef-17c3933d6815 rd.lvm.lv=main/root > rd.lvm.lv=main/swap mitigations=off rhgb quiet rd.driver.blacklist=nouveau > modprobe.blacklist=nouveau pci.blacklist_dev=10de:1f95 > $ dmesg |grep option > $ I suppose so, don't know why.. Anyway, let me Cc Mario in case he has any clue on whether S3 is fully supported on this platform.
+Perry Chen: I don't have a path to confirm this information myself, but I've CC'ed Perry from Dell who might be able to hlep. I would suspect that this system doesn't really support S3. However I would also point out that the latest versions of the NVIDIA proprietary driver does support RTD3, and so if the reason for trying to use S3 was because of power consumption and that's the only remaining issue it's probably worth using the proprietary NVIDIA driver configured with RTD3. Although the XPS 9500 doesn't ship with Linux, this is how Dell typically ships systems that use Suspend to Idle and have discrete NVIDIA graphics.
(In reply to mario.limonciello from comment #19) > +Perry > > Chen: > I don't have a path to confirm this information myself, but I've CC'ed Perry > from Dell who might be able to hlep. > > I would suspect that this system doesn't really support S3. However I would > also point out that the latest versions of the NVIDIA proprietary driver > does support RTD3, and so if the reason for trying to use S3 was because of > power consumption and that's the only remaining issue it's probably worth > using the proprietary NVIDIA driver configured with RTD3. > > Although the XPS 9500 doesn't ship with Linux, this is how Dell typically > ships systems that use Suspend to Idle and have discrete NVIDIA graphics. Let me check with internal team to confirm if the XPS 9500 support S3 As I know ,S3 is not supported any more. Will confirm this again to make sure S3 is really not supported. Perry.
(In reply to mario.limonciello from comment #19) > +Perry > > Chen: > I don't have a path to confirm this information myself, but I've CC'ed Perry > from Dell who might be able to hlep. > > I would suspect that this system doesn't really support S3. However I would > also point out that the latest versions of the NVIDIA proprietary driver > does support RTD3, and so if the reason for trying to use S3 was because of > power consumption and that's the only remaining issue it's probably worth > using the proprietary NVIDIA driver configured with RTD3. > > Although the XPS 9500 doesn't ship with Linux, this is how Dell typically > ships systems that use Suspend to Idle and have discrete NVIDIA graphics. I have no problems running the system with nvidia proprietary drivers. The runtime PM is fine with or without them. The problems I have outside of S3 is that s0ix drains the battery for under 40 hours when suspended for which I have another bug open - https://bugzilla.kernel.org/show_bug.cgi?id=211441. Summary - No SYS%LPI residency when suspended although opportunistic(runtime) s0ix shows signs of life.
Confirmed with the internal team , In XPS 9500 product, only S2I mode is supported by windows and Linux. you can check dmesg , you will see the default mode is s2idle.
Thanks Mario and Perry. Karaivanov, let's switch to https://bugzilla.kernel.org/show_bug.cgi?id=211441 to track the power consumption issue of s2idle.