SystemD does not resume after suspending for some "long" time

to_you_bannana · 2023-07-16 03:04:53

I cannot turn on the system once it has been suspended for some time, and I have to reboot it.

 
systemd[1]: Reached target Sleep.
systemd[1]: Starting NVIDIA system suspend actions...
suspend[156082]: nvidia-suspend.service
logger[156082]: <13>Jul 16 00:13:38 suspend: nvidia-suspend.service
kernel: snd_hda_codec_hdmi hdaudioC1D0: HDMI: invalid ELD data byte 16
systemd[1]: nvidia-suspend.service: Deactivated successfully.
systemd[1]: Finished NVIDIA system suspend actions.
systemd[1]: Starting System Suspend...
systemd-sleep[156097]: Entering sleep state 'suspend'...
kernel: PM: suspend entry (deep)
~
~

UEFI/BIOS has stayed the same, don't have TPM
Kernel: 6.4.1-zen2-1-zen
CPU: AMD Ryzen 5 1500X (8) @ 3.800GHz
GPU: NVIDIA GeForce GTX 1070 Ti
X11
GRUB_CMDLINE_LINUX_DEFAULT="loglevel=7 nvidia-drm.modeset=1 amd_iommu=on iommu=pt" (stayed the same)

seth · 2023-07-16 04:53:12

https://download.nvidia.com/XFree86/Lin … ement.html

NVIDIA Linux kernel module needs to be loaded with the NVreg_PreserveVideoMemoryAllocations=1 module parameter

Do you?

By default, these files are created in /tmp, but this location can be changed with the TemporaryFilePath kernel module parameter, e.g. TemporaryFilePath=/run. The destination file system needs to support unnamed temporary files, and it needs to be large enough to accommodate all video memory copies for the duration of power management cycles.

Is it?

How long™ is long™ (on estimate)?
5m? 1h? 2d? 1w?

Is there a parallel windows installation?
Can you trigger this by suspending the system from the multi-user.target (no GUI running/started, you've plenty of free RAM and the GPU has virtually not been used at all)?

to_you_bannana · 2023-07-16 05:46:38

seth wrote:

https://download.nvidia.com/XFree86/Lin … ement.html
NVIDIA Linux kernel module needs to be loaded with the NVreg_PreserveVideoMemoryAllocations=1 module parameter
Do you?
By default, these files are created in /tmp, but this location can be changed with the TemporaryFilePath kernel module parameter, e.g. TemporaryFilePath=/run. The destination file system needs to support unnamed temporary files, and it needs to be large enough to accommodate all video memory copies for the duration of power management cycles.
Is it?
How long™ is long™ (on estimate)?
5m? 1h? 2d? 1w?
Is there a parallel windows installation?
Can you trigger this by suspending the system from the multi-user.target (no GUI running/started, you've plenty of free RAM and the GPU has virtually not been used at all)?

Ok, I have added the NVreg_PreserveVideoMemoryAllocations parameter, not really sure where to look to see if the Nvidia files are created in /tmp

Long is maybe around 4+ hours or so

Only arch linux is installed

Ill see if this can be triggered without GUI tonight

seth · 2023-07-16 05:51:53

I have added the NVreg_PreserveVideoMemoryAllocations parameter

Where and how? If the answer isn't "kernel commandline" make sure to rebuild the initramfs if you added nvidia there.

not really sure where to look to see if the Nvidia files are created in /tmp

That's the default behavior, my concern was about the "needs to be large enough to accommodate all video memory copies", ie. you need enough free RAM when suspending.

Long is maybe around 4+ hours or so

Certainly sounds like the VRAM decay - what are the symptoms on resume?

to_you_bannana · 2023-07-16 06:41:36

seth wrote:

I have added the NVreg_PreserveVideoMemoryAllocations parameter
Where and how? If the answer isn't "kernel commandline" make sure to rebuild the initramfs if you added nvidia there.
not really sure where to look to see if the Nvidia files are created in /tmp
That's the default behavior, my concern was about the "needs to be large enough to accommodate all video memory copies", ie. you need enough free RAM when suspending.
Long is maybe around 4+ hours or so
Certainly sounds like the VRAM decay - what are the symptoms on resume?

I added it to /etc/modprobe.d/nvidia-power-management.conf as suggested by the arch wiki, already rebuilt initramfs

I have 64GB ram so thats not an issue

Not sure what you means by "on resume", it can't resume so I have to restart. Everythings normal after that, and normal when I resume from a short sleep

seth · 2023-07-16 06:44:47

Does the system power up? Do the fans spin? Is there maybe some sound?
This kind of stuff - VRAM decay primarily leads to garbled textures ie. you don't see anything and the system might stall for a while, esp. w/ some major GL clients (compositor), but if the system just doesn't power up at all, that's unlikely the cause.

to_you_bannana · 2023-07-16 09:53:07

seth wrote:

Does the system power up? Do the fans spin? Is there maybe some sound?
This kind of stuff - VRAM decay primarily leads to garbled textures ie. you don't see anything and the system might stall for a while, esp. w/ some major GL clients (compositor), but if the system just doesn't power up at all, that's unlikely the cause.

Yup, the system powers up alright. Fans spin properly, and the components light up properly as well. I cannot find much about VRAM decay online though

seth · 2023-07-16 11:03:26

The memory on the graphics card isn't properly powered/refreshed during the S3 and after some time becomes a mess.

to_you_bannana · 2023-07-16 14:34:56

seth wrote:

The memory on the graphics card isn't properly powered/refreshed during the S3 and after some time becomes a mess.

Ah, could you suggest some ways on approaching this issue then?

seth · 2023-07-16 14:36:25

That's what https://download.nvidia.com/XFree86/Lin … ement.html is supposed to cover.
Did you reboot w/ the kernel parameter in place and/or test S3 from the multi-user.target?

to_you_bannana · 2023-08-12 01:51:39

seth wrote:

That's what https://download.nvidia.com/XFree86/Lin … ement.html is supposed to cover.
Did you reboot w/ the kernel parameter in place and/or test S3 from the multi-user.target?

Not sure what is meant by S3, but I executed

# systemctl isolate multi-user.target
# systemctl suspend

and I was able to resume from sleep normally

seth · 2023-08-12 06:12:59

https://en.wikipedia.org/wiki/ACPI#Power_states

So, did you read and implement the link I posted?

Arch Linux

#1 2023-07-16 03:04:53

SystemD does not resume after suspending for some "long" time

#2 2023-07-16 04:53:12

Re: SystemD does not resume after suspending for some "long" time

#3 2023-07-16 05:46:38

Re: SystemD does not resume after suspending for some "long" time

#4 2023-07-16 05:51:53

Re: SystemD does not resume after suspending for some "long" time

#5 2023-07-16 06:41:36

Re: SystemD does not resume after suspending for some "long" time

#6 2023-07-16 06:44:47

Re: SystemD does not resume after suspending for some "long" time

#7 2023-07-16 09:53:07

Re: SystemD does not resume after suspending for some "long" time

#8 2023-07-16 11:03:26

Re: SystemD does not resume after suspending for some "long" time

#9 2023-07-16 14:34:56

Re: SystemD does not resume after suspending for some "long" time

#10 2023-07-16 14:36:25

Re: SystemD does not resume after suspending for some "long" time

#11 2023-08-12 01:51:39

Re: SystemD does not resume after suspending for some "long" time

#12 2023-08-12 06:12:59

Re: SystemD does not resume after suspending for some "long" time

Board footer