Suspend-to-RAM: System won't power off, can't be waken up anymore

chris_8bit · 2025-03-14 12:39:11

Hello everyone,

it's been years since I've been active here, but I recently switched back to Linux and Arch as my daily driver (after work related Windows hell for years) and it's REAL good to be back and amazing to see how things have developed. Yet I am running into a small issue that gives me a headache:

I cannot properly suspend my machine to RAM.

When I do this via

systemctl suspend

my screens shut off and so does the power LED on my PC case. However, all fans (CPU, Case) still spin. Going by how suspend/sleep behaves on Windows 11 (which I use in dual-boot config), those fans should turn off, too and there is always a tiny audible "click" from my power supply when my PC does successfully turn off or goes into sleep (on Windows). On my Arch install, that doesn't happen either.
Additionally, once the system goes into this half-sleep mode - for the lack of a better word - it can't be woken up anymore either. So all I can do then is hard reset the system.

Now according to the system, my machine should support suspend-to-RAM:

cat /sys/power/mem_sleep 
s2idle [deep]

And if I do set the suspend mode to s2idle, that works fine (I am using this right now as a fallback). I also set up hibernate, suspending my system to a swap file, but considering that my POST already takes ~10 seconds, it's barely worth it. So I'd love to get suspend-to-RAM, or ideally hybrid-sleep to work.

To give some more info, here is what journalctl says once I go to suspend (or rather hybrid-sleep since that at least unmounts my drives properly and I am less scared or data loss - but the results are the same for regular suspend):

Mar 14 11:12:57 pyra systemd-logind[739]: The system will hybrid sleep now!
Mar 14 11:12:57 pyra NetworkManager[733]: <info>  [1741947177.8657] manager: sleep: sleep requested (sleeping: no  enabled: yes)
Mar 14 11:12:57 pyra NetworkManager[733]: <info>  [1741947177.8658] device (enp6s0): state change: disconnected -> unmanaged (reason>
Mar 14 11:12:57 pyra kernel: r8169 0000:06:00.0 enp6s0: Link is Down
Mar 14 11:12:57 pyra NetworkManager[733]: <info>  [1741947177.8725] device (/net/connman/iwd/0): state change: unavailable -> unmana>
Mar 14 11:12:57 pyra NetworkManager[733]: <info>  [1741947177.8727] device (wlan0): state change: unavailable -> unmanaged (reason '>
Mar 14 11:12:57 pyra NetworkManager[733]: <info>  [1741947177.8732] manager: NetworkManager state is now ASLEEP
Mar 14 11:12:57 pyra systemd[1]: Reached target Sleep.
Mar 14 11:12:57 pyra systemd[1]: Starting System Hybrid Suspend+Hibernate...
Mar 14 11:12:57 pyra systemd[1]: user@969.service: Unit now frozen-by-parent.
Mar 14 11:12:57 pyra systemd[1]: user-969.slice: Unit now frozen-by-parent.
Mar 14 11:12:57 pyra systemd[1]: session-c1.scope: Unit now frozen-by-parent.
Mar 14 11:12:57 pyra systemd[1]: user@0.service: Unit now frozen-by-parent.
Mar 14 11:12:57 pyra systemd[1]: user.slice: Unit now frozen.
Mar 14 11:12:57 pyra systemd[1]: user-0.slice: Unit now frozen-by-parent.
Mar 14 11:12:57 pyra systemd[1]: session-2.scope: Unit now frozen-by-parent.
Mar 14 11:12:57 pyra systemd-sleep[997]: Successfully froze unit 'user.slice'.
Mar 14 11:12:57 pyra systemd-sleep[997]: Performing sleep operation 'hybrid-sleep'...
Mar 14 11:12:57 pyra kernel: PM: hibernation: hibernation entry
Mar 14 11:12:57 pyra kernel: Filesystems sync: 0.008 seconds

So that looks very normal to me and I am at a bit of a loss.
Howevver when my machine comes back from hibernate or s2sleep, I do notice one abnormality in dmesg:

[   75.276531] spd5118 0-0051: PM: dpm_run_callback(): spd5118_resume [spd5118] returns -6
[   75.276549] spd5118 0-0051: PM: failed to resume async: error -6
[   75.276678] spd5118 0-0053: PM: dpm_run_callback(): spd5118_resume [spd5118] returns -6
[   75.276694] spd5118 0-0053: PM: failed to resume async: error -6

If this is related to the issue, I cannot say.

I've also tried some acpi commands in my kernel command line:

acpi_os_name='Microsoft Windows NT' acpi_osi='Windows 2022'

but that didn't do anything either. In fact I am also not sure if I am using these settings correctly.

What else may be interesting is that I am using an nvidia GPU with the binary nvidia driver. Also tried nvidia-open, but same deal.
The nvidia-suspend/resume/hibernate services are all enabled.

What is VERY interesting is that with the regular nvidia setup (i.e. no modifications made after installing the driver), 'systemctl hybrid-sleep' did not work.
When trying this, the system immediately came back with the message:

GPU 0000:01:00.0: PreserveVideoMemoryAllocations module parameter is set. System Power Management attempted without driver procfs suspend interface. Please refer to the 'Configuring Power Management Support' section in the driver README.

And if I would try 'systemctl suspend' right afterwards, it would go to sleep correctly and wake up again!

So my thought was that this error was the culprit. Looking into it, I got hints that I should set the following options for the nvidia module:

options nvidia NVreg_PreserveVideoMemoryAllocations=1 NVreg_TemporaryFilePath=/var/tmp

But this didn't help. The error when going to hybrid-sleep was the same.
So I changed it to

options nvidia NVreg_PreserveVideoMemoryAllocations=0 NVreg_TemporaryFilePath=/var/tmp

That solved the issue (i.e. the error message from the nvidia module was gone), but it only meant that hybrid-sleep was now also not suspending the system correctly:
LED turns off, fans stay on, system becomes unresponsive.

So either I am still doing something wrong with the nvidia options OR failing to go to suspend once (via failed hybrid-sleep) did... something that makes a following new attempt (via suspend) work....
This is such a weird behavior, it's downright frustrating, because this is not something I can really use as a workaround.

So now after days of trying (and my file system being really mad at me at this point), I hope one of you can help. Even if it's just some shots in the dark, I am happy to try everything.

Addendum:
I forgot, I should also give some information about my hardware, mainly the mainboard I guess:
Mainboard: Gigabyte Z790 Aorus Elite AX (rev1.x), equipped with the newest Firmware version FLb from Dec 4th 2024
CPU: Intel i7 13700KF
GPU: Gigabyte AERO 4080

Last edited by chris_8bit (2025-03-14 13:16:46)

seth · 2025-03-14 15:27:51

I use in dual-boot config

3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.
Especially on this topic.

[   75.276531] spd5118 0-0051: PM: dpm_run_callback(): spd5118_resume [spd5118] returns -6

Themal sensor for DDR5 RAM - you can try to blacklist the module, but I don't really expect this to be an actual problem.

NVreg_PreserveVideoMemoryAllocations=1 is the current default, but there seems an inherent contradiction w/ hibernation if you've the nvidia modules in the initramfs, https://bbs.archlinux.org/viewtopic.php?id=285508
So remove them (and in doubt the kms hook) from there.

As for s2idle ./. s3 the sad reality is that S3 support is increasingly step-childed by board vendors (and/as windows will default to s2idle as well)

* fix the fast start condition (the voodoo reboots are not a joke. well, the voodoo aspect maybe, but not the necessity)
* remove the nvidia modules from the initramfs, add "nvidia_drm.modeset=1" to the https://wiki.archlinux.org/title/Kernel_parameters to get rid of the simpledrm device
* re-enable VRAM preservation
* boot, hybrid/sleep and then report on the status quo and please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

chris_8bit · 2025-03-14 16:12:40

@seth

Thank you so much for your reply.
I should have mentioned I disabled Fast-Boot/Hibernate on Windows a long time ago. I am pretty sure I even did that because of one of your posts I found when I first started tinkering with Suspend. Either way I punched in

powercfg /H off

on Windows again, rebooted to it twice and twice on Linux (I believe that's the Voodoo you're referring to. In the meantime I removed the

nvidia.modeset=1

parameter from the kernel arguments (had it there before, might as well check if that was the cause - don't really have any nvidia modules there or in mkinitcpio.conf).
Put it into modeprobe.d/nvidia.conf file where the

options nvidia NVreg_PreserveVideoMemoryAllocations=0

still resides since otherwise the machine still refuses to go to hybrid-sleep:

Mar 14 16:55:48 pyra kernel: NVRM: GPU 0000:01:00.0: PreserveVideoMemoryAllocations module parameter is set. System Power Management attempted without driver procfs suspend interface. Please refer to the 'Configuring Power Management Support' section in the driver README.
Mar 14 16:55:48 pyra kernel: nvidia 0000:01:00.0: PM: pci_pm_suspend(): nv_pmops_suspend [nvidia] returns -5
Mar 14 16:55:48 pyra kernel: nvidia 0000:01:00.0: PM: dpm_run_callback(): pci_pm_suspend returns -5
Mar 14 16:55:48 pyra kernel: nvidia 0000:01:00.0: PM: failed to suspend async: error -5

But with

options nvidia NVreg_PreserveVideoMemoryAllocations=0

hybrid-sleep still goes to an unresponsive system. Power LED turns off, fans continue to spin.

So now here is the full journal from that session where I attempted to hybrid-sleep + the following resume from hibernation file:
https://0x0.st/8Qqr.txt
(suspend starts at Mar 14 16:57:10

Last edited by chris_8bit (2025-03-15 07:32:56)

seth · 2025-03-15 23:32:27

Mar 14 16:56:48 pyra systemd[1]: Finished Remount Root and Kernel File Systems.
Mar 14 16:56:49 pyra kernel: nvidia: loading out-of-tree module taints kernel.

nvidia isn't in the initramfs ("good")

Mar 14 16:56:50 pyra nvidia-persistenced[727]: Started (727)
Mar 14 16:56:50 pyra /usr/bin/nvidia-powerd[725]: nvidia-powerd version:1.0(build 1)
…
Mar 14 16:56:50 pyra /usr/bin/nvidia-powerd[725]: Found unsupported configuration. Exiting...
Mar 14 16:56:50 pyra systemd[1]: nvidia-powerd.service: Main process exited, code=exited, status=1/FAILURE
Mar 14 16:56:50 pyra systemd[1]: nvidia-powerd.service: Failed with result 'exit-code'.
Mar 14 16:56:50 pyra systemd[1]: Started NVIDIA Persistence Daemon.

noise, but you could disable nvidia-powerd.service (unlikely relevant)

Mar 14 16:56:51 pyra systemd-logind[726]: New session c1 of user sddm.

Have you tried the behavior from the multi-user.target (2nd link below) and esp. not SDDM?

Mar 14 16:57:09 pyra login[945]: ROOT LOGIN ON tty4

You're logging in on the console (but SDDM is still running at this point)

Mar 14 16:57:10 pyra systemd-logind[726]: The system will hybrid sleep now!
Mar 14 16:57:10 pyra systemd[1]: Reached target Sleep.
…
Mar 14 16:58:22 pyra systemd-sleep[988]: System returned from sleep operation 'hybrid-sleep'.
Mar 14 16:58:22 pyra bluetoothd[721]: Battery Provider Manager destroyed
Mar 14 16:58:22 pyra systemd[1]: Starting Load/Save RF Kill Switch Status...
Mar 14 16:58:22 pyra systemd[1]: systemd-hybrid-sleep.service: Deactivated successfully.
Mar 14 16:58:22 pyra systemd[1]: Finished System Hybrid Suspend+Hibernate.
Mar 14 16:58:22 pyra systemd[1]: Reached target Hybrid Suspend+Hibernate.
Mar 14 16:58:22 pyra systemd[1]: Stopped target Sleep.
Mar 14 16:58:22 pyra systemd-logind[726]: Operation 'hybrid-sleep' finished.

System enters hibernation and wakes 72s later.

Mar 14 16:58:28 pyra systemd-logind[726]: The system will reboot now!

6s later something triggers a reboot.

There's actually no indication for problems (the thermal sensor aside), there's notably no

GPU 0000:01:00.0: PreserveVideoMemoryAllocations module parameter is set. System Power Management attempted without driver procfs suspend interface. Please refer to the 'Configuring Power Management Support' section in the driver README.

and the system wasn't hard-rebooted either?
Is this w/ "nvidia NVreg_PreserveVideoMemoryAllocations=0"?
Did you also deactivate the userspace services, https://wiki.archlinux.org/title/NVIDIA … er_suspend ?
The don#t show up in the journal.

nvidia.modeset=1

The correct parameter would be "nvidia_drm.modeset=1" and since this seems to be limited to the framebuffer device, you should add that and also test the impact of "nvidia_drm.fbdev=0"
Next to that enable "nvidia.NVreg_PreserveVideoMemoryAllocations=1" and also the userspace services, if the system still fails to sleep/hibernate, post a journal of /that/ attempts.

chris_8bit · 2025-03-16 09:10:37

noise, but you could disable nvidia-powerd.service (unlikely relevant)

It is irrelevant indeed. Before I posted here I tried changing the state of that service as well as the nvidia-persistence.service. Neither of them change anything on the outcome.

System enters hibernation and wakes 72s later.

Yes. That was me sending the system to hybrid-sleep, waiting if it would turn off. But then I had to press the reset button as I could not wake it up anymore. Hence it resumed from hibernation.

6s later something triggers a reboot.

That was also me. Once the system came back from hibernation (after the failed suspend), I rebooted it once more so that when I would upload the journal, it would be more manageable and not contain a lot of KDE spam. (Did the same with the log further below)

There's actually no indication for problems (the thermal sensor aside), there's notably no
GPU 0000:01:00.0: PreserveVideoMemoryAllocations module parameter is set. System Power Management attempted without driver procfs suspend interface. Please refer to the 'Configuring Power Management Support' section in the driver README.
and the system wasn't hard-rebooted either?
Is this w/ "nvidia NVreg_PreserveVideoMemoryAllocations=0"?
Did you also deactivate the userspace services, https://wiki.archlinux.org/title/NVIDIA … er_suspend ?
The don#t show up in the journal.

Yes this is with "nvidia NVreg_PreserveVideoMemoryAllocations=0". Setting that to true, I cannot hybrid-sleep at all. I CAN suspend, but that just results in the same outcome: System becomes unresponsive, logs show the system entered sleep. Just that when I reset it then, the filesystem gets angry with me. Unless if I let hybrid-sleep fail and THEN run systemctl suspend.... then sleeping works successfully. Which still drives me up the wall because it shows my system is able to sleep.

I.e. if I set "nvidia NVreg_PreserveVideoMemoryAllocations=1"
Then try "systemctl hybrid-sleep" - which fails - I can do "systemctl suspend" and it will work until I reboot the machine. If I only do "systemctl suspend" without (failed) hybrid-sleep beforehand, the system becomes unresponsive yet again.

So now I tried your other suggestions and I expanded the kernel command line with:

systemd.unit=multi-user.target nvidia_drm.modeset=1 nvidia_drm.fbdev=0

and tried to hybrid-sleep once more while "nvidia NVreg_PreserveVideoMemoryAllocations=0".

I should also mention that despite the logs not saying anything about them, the nvidia services are all enabled:

[chris@pyra ~]$ systemctl list-unit-files | grep nvidia
nvidia-hibernate.service                     enabled         disabled
nvidia-persistenced.service                  enabled         disabled
nvidia-powerd.service                        enabled         disabled
nvidia-resume.service                        enabled         disabled
nvidia-suspend-then-hibernate.service        enabled         disabled
nvidia-suspend.service                       enabled         disabled

The outcome was the same:
https://0x0.st/8QVZ.txt
at Mar 16 09:08:35 the system pretended to enter hybrid-sleep. The Power LED turned off and the fans kept spinning. It's weird to me the power LED turns off. That doesn't even happen on s2idle (where I can wake up the system again). If I do send the system to suspend-to-RAM on Windows, the power LED turns off together with the fans at the exact same time. I really do wonder if my mainboard messes things up.

Or if I am still doing things wrong. I apologize in advance if I haven't followed some of your or the wiki's advice properly.

The only other thing I could imagine would be to completely uninstall the nvidia driver which would (at least I hope so) isolate whether the issue stems from the nvidia driver or not.

EDIT: For good measure I now also set "nvidia NVreg_PreserveVideoMemoryAllocations=1", tried to put the system to hybrid-sleep, which failed and then successfully went to regular suspend (deep) afterwards:
https://0x0.st/8QVM.txt
Once again, if I would try suspending without failed hybrid-sleep beforehand, the system would become unresponsive in the same way as with the hybrid-sleep + "nvidia NVreg_PreserveVideoMemoryAllocations=0"
The only thing I can see - and that may be the crucial point here: After hybrid-sleep failed and I try to put the system to regular suspend(to RAM, deep), I first see the logs mention the nvidia-suspend.service kicking in. As stated before, the services are all enabled. But they only ever come on after that one failed hybrid-sleep.

EDIT2: And here is the log of a regular suspend with nvidia_drm.modeset=1 nvidia_drm.fbdev=0 and "nvidia NVreg_PreserveVideoMemoryAllocations=1" - without trying hybrid-sleep before:
https://0x0.st/8QVd.txt
As expected, the suspend resulted in an unresponsive system again (fans still spinning). Although that operation does show the nvidia-suspend service kicking in as expected. But there is a lot of back and forth - and I admit, I do not understand what exactly is happening there. BEst I can tell it first attempts to do s2idle and then to deep as the nvidia-suspend/resume services react to that? Not 100% sure

EDIT3:
Even when I attempt to force:

MemorySleepMode=deep
SuspendState=mem

in a created /etc/systemd/sleep.conf.d/sleep.conf
it seems that just like in the log posted in EDIT2, systemctl suspend attempts s2idle first, wakes up from that again, tries deep and somehow screws itself up. That's the best I can read from this.

As a fallback, I am now using

MemorySleepMode=deep
SuspendState=freeze

but just as with

MemorySleepMode=s2idle

that technically keeps the machine "on". Just looks as if my KDE session gets locked and screens turn off (Power LED stays on, too). I guess it's better than nothing. And if I set up some scripts to disable the few LEDs I have on my mainboard I could save at least a bit of power.

Last edited by chris_8bit (2025-03-16 11:17:32)

seth · 2025-03-16 16:06:57

Once again, if I would try suspending without failed hybrid-sleep beforehand, the system would become unresponsive in the same way as with the hybrid-sleep

This is what we want to address and

Mar 16 10:20:15 pyra kernel: NVRM: GPU 0000:01:00.0: PreserveVideoMemoryAllocations module parameter is set. System Power Management attempted without driver procfs suspend interface. Please refer to the 'Configuring Power Management Support' section in the driver README.
Mar 16 10:20:15 pyra kernel: nvidia 0000:01:00.0: PM: pci_pm_freeze(): nv_pmops_freeze [nvidia] returns -5
Mar 16 10:20:15 pyra kernel: nvidia 0000:01:00.0: PM: dpm_run_callback(): pci_pm_freeze returns -5

this here means that the nvidia services are not enabled.

The services however show up in the journal for

EDIT2: And here is the log of a regular suspend with nvidia_drm.modeset=1 nvidia_drm.fbdev=0 and "nvidia NVreg_PreserveVideoMemoryAllocations=1" - without trying hybrid-sleep before:

but that does *not* have "nvidia_drm.modeset=1", which is why there's

Mar 16 11:25:56 pyra kernel: [drm] Initialized simpledrm 1.0.0 for simple-framebuffer.0 on minor 0

Fix that, we're going to focus on that configuration (no hibernation etc. the hybrid-sleep is S2/S3 + S4 later what just complicates things)

Mar 16 11:26:19 pyra systemd[1]: Reached target Sleep.
Mar 16 11:26:19 pyra systemd[1]: Starting NVIDIA system suspend actions...
Mar 16 11:26:19 pyra suspend[1013]: nvidia-suspend.service
Mar 16 11:26:19 pyra logger[1013]: <13>Mar 16 11:26:19 suspend: nvidia-suspend.service
Mar 16 11:26:20 pyra systemd[1]: nvidia-suspend.service: Deactivated successfully.
Mar 16 11:26:20 pyra systemd[1]: Finished NVIDIA system suspend actions.
Mar 16 11:26:20 pyra systemd[1]: nvidia-suspend.service: Consumed 460ms CPU time, 546.4M memory peak.
Mar 16 11:26:20 pyra systemd[1]: Starting System Suspend...
Mar 16 11:26:20 pyra systemd-sleep[1024]: User sessions remain unfrozen on explicit request ($SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0).
Mar 16 11:26:20 pyra systemd-sleep[1024]: This is not recommended, and might result in unexpected behavior, particularly
Mar 16 11:26:20 pyra systemd-sleep[1024]: in suspend-then-hibernate operations or setups with encrypted home directories.
Mar 16 11:26:20 pyra systemd-sleep[1024]: Performing sleep operation 'suspend'...
Mar 16 11:26:20 pyra kernel: PM: suspend entry (s2idle)
Mar 16 11:26:20 pyra kernel: Filesystems sync: 0.209 seconds
Mar 16 11:26:28 pyra kernel: Freezing user space processes
Mar 16 11:26:28 pyra kernel: Freezing user space processes completed (elapsed 0.001 seconds)
Mar 16 11:26:28 pyra kernel: OOM killer disabled.
Mar 16 11:26:28 pyra kernel: Freezing remaining freezable tasks
Mar 16 11:26:28 pyra kernel: Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
Mar 16 11:26:28 pyra kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Mar 16 11:26:28 pyra kernel: sd 2:0:0:0: [sda] Synchronizing SCSI cache
Mar 16 11:26:28 pyra kernel: ata3.00: Entering standby power mode
Mar 16 11:26:28 pyra kernel: spd5118 0-0053: Failed to write b = 0: -6
Mar 16 11:26:28 pyra kernel: spd5118 0-0053: PM: dpm_run_callback(): spd5118_resume [spd5118] returns -6
Mar 16 11:26:28 pyra kernel: spd5118 0-0053: PM: failed to resume async: error -6
Mar 16 11:26:28 pyra kernel: spd5118 0-0051: Failed to write b = 0: -6
Mar 16 11:26:28 pyra kernel: spd5118 0-0051: PM: dpm_run_callback(): spd5118_resume [spd5118] returns -6
Mar 16 11:26:28 pyra kernel: spd5118 0-0051: PM: failed to resume async: error -6
Mar 16 11:26:28 pyra kernel: nvme nvme1: D3 entry latency set to 10 seconds
Mar 16 11:26:28 pyra kernel: nvme nvme1: 24/0/0 default/read/poll queues
Mar 16 11:26:28 pyra kernel: nvme nvme0: 8/0/0 default/read/poll queues
Mar 16 11:26:28 pyra kernel: OOM killer enabled.
Mar 16 11:26:28 pyra kernel: Restarting tasks ... done.
Mar 16 11:26:28 pyra kernel: random: crng reseeded on system resumption
Mar 16 11:26:28 pyra kernel: PM: suspend exit
Mar 16 11:26:28 pyra systemd-sleep[1024]: System returned from sleep operation 'suspend'.
Mar 16 11:26:28 pyra kernel: ata5: SATA link down (SStatus 4 SControl 300)
Mar 16 11:26:28 pyra kernel: ata7: SATA link down (SStatus 4 SControl 300)
Mar 16 11:26:28 pyra kernel: ata2: SATA link down (SStatus 4 SControl 300)
Mar 16 11:26:28 pyra kernel: ata4: SATA link down (SStatus 4 SControl 300)
Mar 16 11:26:28 pyra kernel: ata8: SATA link down (SStatus 4 SControl 300)
Mar 16 11:26:28 pyra kernel: ata1: SATA link down (SStatus 4 SControl 300)
Mar 16 11:26:28 pyra kernel: ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Mar 16 11:26:28 pyra kernel: ata6: SATA link down (SStatus 4 SControl 300)
Mar 16 11:26:28 pyra kernel: ata3.00: supports DRM functions and may not be fully accessible
Mar 16 11:26:28 pyra kernel: sd 2:0:0:0: [sda] Starting disk
Mar 16 11:26:28 pyra kernel: ata3.00: supports DRM functions and may not be fully accessible
Mar 16 11:26:28 pyra kernel: ata3.00: configured for UDMA/133
Mar 16 11:26:28 pyra kernel: ahci 0000:00:17.0: port does not support device sleep
Mar 16 11:26:28 pyra kernel: ata3.00: Enabling discard_zeroes_data
Mar 16 11:26:28 pyra systemd[1]: systemd-suspend.service: Deactivated successfully.
Mar 16 11:26:28 pyra systemd[1]: Finished System Suspend.
Mar 16 11:26:28 pyra systemd[1]: Stopped target Sleep.

1. Make sure to acutally add those kernel parameters (resp. for fbdev you'll have to test both variants)
2. blacklist spd5118 to get that out of the way
3. https://wiki.archlinux.org/title/Solid_ … leshooting

nvme_core.default_ps_max_latency_us=0 iommu=soft pcie_aspm=off pcie_port_pm=off

(the system claims no ASPM supportl, we'll still nuke it)

Then there's some noise around the bus where

Mar 16 11:25:56 pyra kernel: ata3.00: ATA-11: Samsung SSD 860 EVO 2TB, RVT04B6Q, max UDMA/133
Mar 16 11:25:56 pyra kernel: ata3.00: 3907029168 sectors, multi 1: LBA48 NCQ (depth 32), AA
Mar 16 11:25:56 pyra kernel: ata3.00: Features: Trust Dev-Sleep NCQ-sndrcv

is attached.
So we're also gonna take away ncq, "libata.force=noncq" and set it to medium_power, https://wiki.archlinux.org/title/Power_ … Management - a lot of drives got afforded med_power_with_dipm w/o properly supporting it.

Then try "deep" and "s2idle" sleep, post updated journals - make sure to use the kernel commandline for all these parameters to
1. log them
2. apply them no matter what
3. the modeset parameter will actually only block the simpledrm device this way

Or if I am still doing things wrong. I apologize in advance

S[2-4] struggles are unfortunately common since the ACPI is usually written by board vendors by poking around until windows works.
Speaking of which

Mar 16 11:25:56 pyra kernel: DMI: Gigabyte Technology Co., Ltd. Z790 AORUS ELITE AX/Z790 AORUS ELITE AX, BIOS FLb 12/04/2024

Is there an updated FW available for the board?

chris_8bit · 2025-03-16 17:46:04

Thanks so much for your replies and the patience despite my mistakes.

So I have now added those kernel parameters - which you should be able to see in my logs and made three different attempts (I hope I did it all correctly):

1) deep sleep with all kernel parameters as suggested:

cat /etc/systemd/sleep.conf.d/sleep.conf
MemorySleepMode=deep
SuspendState=mem

https://0x0.st/8Qy0.txt

Result: System yet again becomes unresponsive, have to hard reset.

2) deep sleep but this time I went into the BIOS/UEFI settings and turned Native ASPM to ENABLED (was DISABLED before) and via Grub command-line I set nvidia_drm.fbdev=1

cat /etc/systemd/sleep.conf.d/sleep.conf
MemorySleepMode=deep
SuspendState=mem

https://0x0.st/8QyR.txt

Result: Same as before.

3) Leaving Native ASPM enabled, nvidia_drm.fbdev=0 again but changed sleep mode

cat /etc/systemd/sleep.conf.d/sleep.conf
MemorySleepMode=deep
SuspendState=freeze

https://0x0.st/8Qy7.txt

Result: System went to idle (s2idle I assume. displays turned off, everything else stayed on), I was able to wake it up again. then I rebooted.

EDIT: Forgot to mention: Firmware FLb from Dec 4th 2024 is currently the most up to date Firmware. I updated that recently and once before to a BETA firmware FJ (not available on Gigabyte's website anymore) to fix the potential killing of my CPU due to voltage shenanigans. Hence I was keeping tabs on updating that as often as I could.

Last edited by chris_8bit (2025-03-16 17:51:58)

seth · 2025-03-17 08:19:36

Apparently "Native ASPM" enables ASPM resp. delegates it to the OS - does any configuration /not/ work with that setting?
(Even if you scrap pcie_aspm=off and pretty much all other mitigational parameters)

chris_8bit · 2025-03-18 15:12:14

seth wrote:

Apparently "Native ASPM" enables ASPM resp. delegates it to the OS - does any configuration /not/ work with that setting?
(Even if you scrap pcie_aspm=off and pretty much all other mitigational parameters)

Right: The BIOS/UEFI claims that ASPM Disabled means "ASPM handled by BIOS/UEFI" while Enabled means it "being handled by the OS". I have to run a few more days without all the additional kernel parameters to see if it causes some weird side effects. It was disabled/BIOS-handled by default and I just left it like that (because modern UEFI settings menus are so overwhelming). But I did play with that setting months ago when I first tinkered with suspend-to-RAM as it's one of the few power management related settings the UEFI menu even offers.

chris_8bit · 2025-04-09 08:41:17

Update:
I tested the "ASPM Enabled/OS-controlled" for a while and while most things seemed to work fine, I noticed that my ethernet adapter apparently didn't like it so much. While download/upload speeds for singular files were all fine, when opening a website, I could see individual elements of websites loading in with speeds I haven't seen for 25 years. So I switched back to "ASPM Disabled/BIOS-controlled" and now that's fine again. Just took me a while to really make sure this was related to the ASPM setting. For whatever reason - I shall not question it.

Aside of that I have made no further progress on getting suspend-to-RAM to work. So right now I just use s2idle ... or I'll throw in "systemctl hybrid-sleep" which - as noted above - fails, but once it does, suspend-to-RAM starts to work. Which sounds like the premise of an xkcd comic, but I legitimately don't know what else to try anymore.

seth · 2025-04-09 14:54:26

Do you currently still use "pcie_aspm=off"?
Does https://aur.archlinux.org/packages/r8125-dkms perform better?

chris_8bit · 2025-04-10 18:32:57

seth wrote:

Do you currently still use "pcie_aspm=off"?
Does https://aur.archlinux.org/packages/r8125-dkms perform better?

At the moment I am not using this argument, but I will try it again soon, to see if that makes any difference. I admit, it's not easy to test because my internet connection/signal strength is of varying quality (in part because of the town's infrastructure and part of the old endpoint wiring in the house) - but it's cheap so I can't complain. And "more than usual" varying speeds is the only thing I could observe with "ASPM Enabled/OS controlled", but if I had to be honest I could not be sure as I lack a second PC to test ethernet speeds. So it's also gonna be hard to tell whether pcie_aspm=off of the kernel module from the AUR will make a further difference.

Arch Linux

#1 2025-03-14 12:39:11

Suspend-to-RAM: System won't power off, can't be waken up anymore

#2 2025-03-14 15:27:51

Re: Suspend-to-RAM: System won't power off, can't be waken up anymore

#3 2025-03-14 16:12:40

Re: Suspend-to-RAM: System won't power off, can't be waken up anymore

#4 2025-03-15 23:32:27

Re: Suspend-to-RAM: System won't power off, can't be waken up anymore

#5 2025-03-16 09:10:37

Re: Suspend-to-RAM: System won't power off, can't be waken up anymore

#6 2025-03-16 16:06:57

Re: Suspend-to-RAM: System won't power off, can't be waken up anymore

#7 2025-03-16 17:46:04

Re: Suspend-to-RAM: System won't power off, can't be waken up anymore

#8 2025-03-17 08:19:36

Re: Suspend-to-RAM: System won't power off, can't be waken up anymore

#9 2025-03-18 15:12:14

Re: Suspend-to-RAM: System won't power off, can't be waken up anymore

#10 2025-04-09 08:41:17

Re: Suspend-to-RAM: System won't power off, can't be waken up anymore

#11 2025-04-09 14:54:26

Re: Suspend-to-RAM: System won't power off, can't be waken up anymore

#12 2025-04-10 18:32:57

Re: Suspend-to-RAM: System won't power off, can't be waken up anymore

Board footer