NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

bertieb · 2025-01-17 13:06:17

obap74 wrote:

Something that has been working reliably for me in the last few weeks (GTX 970 / 6.6.67 kernel / NVIDIA 550.142) is to suspend from a TTY while connected with another user (works with root user as well)

Interesting- does this have to be a physical tty, have you tried over ssh too? Unrelated to suspend I've had issues in the past in which switching to a console tty and back to graphical has 'un-stuck' problems (by triggering a reload of the framebuffer or similar perhaps); I could see the tty switching being an integral part of the procedure due to some interaction with PVMA.

obap74 · 2025-01-17 18:23:46

bertieb wrote:

obap74 wrote:
Something that has been working reliably for me in the last few weeks (GTX 970 / 6.6.67 kernel / NVIDIA 550.142) is to suspend from a TTY while connected with another user (works with root user as well)
Interesting- does this have to be a physical tty, have you tried over ssh too? Unrelated to suspend I've had issues in the past in which switching to a console tty and back to graphical has 'un-stuck' problems (by triggering a reload of the framebuffer or similar perhaps); I could see the tty switching being an integral part of the procedure due to some interaction with PVMA.

I meant regular TTYs, e.g. from TTY2 with Ctrl+Alt+F2. I haven't tried over SSH but I don't think this would work since the machine would resume on the X session (TTY1 in my case).

lorenzol36 · 2025-01-22 01:34:52

My system is now suspending and resuming fine with kernel 6.12.9 and drivers 565.77-11 (GTX950). I've had a 100% success rate during the last few days. I'm on a clean install of the system and everything drivers related is on default.
I should only mention that I'm not directly using Arch, but I'm using Artix, so I had to manually enable both the suspend and resume services in /lib64/elogind/system-sleep/nvidia, otherwise the system wouldn't even go to sleep now that the PreserveVideoMemoryAllocation is activated by default.
This seems like a dream considering that this problem had been going on for about a year now. Now I'm afraid to update kernel and drivers again...

Last edited by lorenzol36 (2025-01-22 01:35:15)

Tharbad · 2025-02-04 14:57:54

Currently using nvidia 560.35.03-19 and kernel 6.11.9.
The problem is with the nvidia driver. But since kernel 6.12 can't be built against nvidia 560.35.03-19 I had to freeze kernel updates too.

@lorenzol36 Current kernel version is 6.13 and nvidia is 670. Can you verify with these versions too?

obap74 · 2025-02-24 18:10:04

obap74 wrote:

Something that has been working reliably for me in the last few weeks (GTX 970 / 6.6.67 kernel / NVIDIA 550.142) is to suspend from a TTY while connected with another user (works with root user as well) with:
exec systemctl suspend
exec allows to log out after executing the command. This avoids getting an unlocked session after resuming the machine, I'm back to the login prompt.
Then, I can switch to TTY1 where my regular user is connected with my X session. I'm then met with xsecurelock (that is run before suspend via a systemd service unit) and I can unlock my session just fine.
Unfortunately, this doesn't work with 6.12.9 kernel + NVIDIA 565.77-3. Although the machine resumes fine, after switching to TTY1, all I get is a black screen with my mouse cursor and all I can do is to restart AwesomeWM.

This trick still works for me on my Gentoo system after updating from 6.6.74 to 6.12.16 (using 550.144.03).

I haven't tried 570.86.16 but considering it wouldn't work on Arch with 565.77.3, chances are it won't work either.

lorenzol36 · 2025-02-26 19:12:46

Tharbad wrote:

@lorenzol36 Current kernel version is 6.13 and nvidia is 670. Can you verify with these versions too?

Yes, it's still working fine for me!

Last edited by lorenzol36 (2025-02-26 19:13:08)

Ristovski · 2025-02-27 08:25:50

obap74 wrote:

obap74 wrote:
Something that has been working reliably for me in the last few weeks (GTX 970 / 6.6.67 kernel / NVIDIA 550.142) is to suspend from a TTY while connected with another user (works with root user as well) with:
exec systemctl suspend
exec allows to log out after executing the command. This avoids getting an unlocked session after resuming the machine, I'm back to the login prompt.
Then, I can switch to TTY1 where my regular user is connected with my X session. I'm then met with xsecurelock (that is run before suspend via a systemd service unit) and I can unlock my session just fine.
Unfortunately, this doesn't work with 6.12.9 kernel + NVIDIA 565.77-3. Although the machine resumes fine, after switching to TTY1, all I get is a black screen with my mouse cursor and all I can do is to restart AwesomeWM.
This trick still works for me on my Gentoo system after updating from 6.6.74 to 6.12.16 (using 550.144.03).
I haven't tried 570.86.16 but considering it wouldn't work on Arch with 565.77.3, chances are it won't work either.

I'm on Gentoo 6.12.0 with 570.86.16 on a RTX 4070 Ti Super (AD103) and this is _still_ the only method that works fwiw

Tharbad · 2025-03-04 14:02:01

@seth Can you point me to the patches required?
I encountered some weird bugs after core packages update. Seems I've no choice.

seth · 2025-03-04 14:27:29

Patches?
Do you mean "how to use some 565xx driver with the latest kernel"?
https://archive.archlinux.org/packages/n/nvidia-dkms/
https://archive.archlinux.org/packages/n/nvidia-utils/
And you'll need the linux-headers package (or linux-lts-headers etc.)

dkms will automatically build modules for all kernels on kernel or driver intallation/updates - in doubt you can manually trigger a rebuild: https://wiki.archlinux.org/title/Dynami … ld_modules

Tharbad · 2025-03-04 14:48:26

seth wrote:

Patches?
Do you mean "how to use some 565xx driver with the latest kernel"?
https://archive.archlinux.org/packages/n/nvidia-dkms/
https://archive.archlinux.org/packages/n/nvidia-utils/
And you'll need the linux-headers package (or linux-lts-headers etc.)
dkms will automatically build modules for all kernels on kernel or driver intallation/updates - in doubt you can manually trigger a rebuild: https://wiki.archlinux.org/title/Dynami … ld_modules

There are build errors:

nvidia-modeset/nvidia-modeset-linux.c:1087:24: warning: no previous prototype for ‘nvkms_open_common’ [-Wmissing-prototypes]
 1087 | struct nvkms_per_open *nvkms_open_common(enum NvKmsClientType type,
      |                        ^~~~~~~~~~~~~~~~~
nvidia-modeset/nvidia-modeset-linux.c:1139:6: warning: no previous prototype for ‘nvkms_close_pm_locked’ [-Wmissing-prototypes]
 1139 | void nvkms_close_pm_locked(struct nvkms_per_open *popen)
      |      ^~~~~~~~~~~~~~~~~~~~~
nvidia-modeset/nvidia-modeset-linux.c:1202:5: warning: no previous prototype for ‘nvkms_ioctl_common’ [-Wmissing-prototypes]
 1202 | int nvkms_ioctl_common
      |     ^~~~~~~~~~~~~~~~~~
nvidia-drm/nvidia-drm-drv.c:209:6: error: ‘const struct drm_mode_config_funcs’ has no member named ‘output_poll_changed’
  209 |     .output_poll_changed = nv_drm_output_poll_changed,
      |      ^~~~~~~~~~~~~~~~~~~
nvidia-drm/nvidia-drm-drv.c:209:28: error: initialization of ‘struct drm_atomic_state * (*)(struct drm_device *)’ from incompatible pointer type ‘void (*)(struct drm_device *)’ [-Wincompatible-pointer-types]
  209 |     .output_poll_changed = nv_drm_output_poll_changed,
      |                            ^~~~~~~~~~~~~~~~~~~~~~~~~~
nvidia-drm/nvidia-drm-drv.c:209:28: note: (near initialization for ‘nv_mode_config_funcs.atomic_state_alloc’)
  CC [M]  nvidia-drm/nvidia-drm-fence.o
  CC [M]  nvidia-drm/nvidia-drm-helper.o
make[4]: *** [/usr/lib/modules/6.13.5-zen1-1-zen/build/scripts/Makefile.build:196: nvidia-drm/nvidia-drm-drv.o] Error 1
make[4]: *** Waiting for unfinished jobs....
make[3]: *** [/usr/lib/modules/6.13.5-zen1-1-zen/build/Makefile:1982: .] Error 2
make[2]: *** [/usr/lib/modules/6.13.5-zen1-1-zen/build/Makefile:251: __sub-make] Error 2
make[2]: Leaving directory '/var/lib/dkms/nvidia/560.35.03/build'
make[1]: *** [Makefile:251: __sub-make] Error 2
make[1]: Leaving directory '/usr/lib/modules/6.13.5-zen1-1-zen/build'
make: *** [Makefile:89: modules] Error 2

seth · 2025-03-04 14:55:50

Are you dead set on 560.35 ?
(I think that part of the API changed w/ 6.12, 565.57.01 should still build w/o intervention)

Tharbad · 2025-03-04 15:10:48

seth wrote:

Are you dead set on 560.35 ?
(I think that part of the API changed w/ 6.12, 565.57.01 should still build w/o intervention)

Yes. Anything above I get the bug.

seth · 2025-03-04 17:05:08

The 535xx and 550xx drivers are maintained in the AUR, otherwise you'll have to import one of https://github.com/NVIDIA/open-gpu-kern … issues/708 or https://gist.github.com/joanbm/a6d3f7f8 … 34c0f1d64e

Tharbad · 2025-03-04 17:08:28

AUR has nvidia-dkms 550.144.03-1 already. As much as I would like to build a custom kernel, I also need a working PC.
I'll use that.

anonking1977 · 2025-04-09 12:20:17

Anyways i also have problem with hibernation with nvidia driver installed.

Main culprit is this:

Putting resume on the far right will result in a black screen (i removed kms module because i am using dkms)
#HOOKS=(base udev resume autodetect microcode modconf keyboard keymap consolefont block encrypt lvm2 filesystems fsck)

Putting resume to the right will result a reboot and not hibernation: #HOOKS=(base udev autodetect microcode modconf keyboard keymap consolefont block encrypt lvm2 filesystems resume fsck)
(even putting resume left to filesystem wont change any difference)

seth · 2025-04-09 15:49:05

https://bbs.archlinux.org/viewtopic.php?id=285508

anonking1977 · 2025-04-09 18:17:34

seth wrote:

https://bbs.archlinux.org/viewtopic.php?id=285508

setting nvidia_drm = 1 will slow down the boot time.

V1del · 2025-04-09 18:42:33

How so? But you generally really want that set for many more modern mechanisms to work properly.

seth · 2025-04-09 19:51:34

Leaving aside that it does not and that it's also the standard setting anyway, it has nothing to do w/ the matter at hand.
And with that in mind, @anonking1977, please post your complete system journal for some boot after a botched resume from hibernation, eg.

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

for the previous boot and your entire mkinitcpio.conf responsible for that specific boot.

anonking1977 · 2025-04-09 19:53:36

V1del wrote:

How so? But you generally really want that set for many more modern mechanisms to work properly.

Ok i tried.

But i still couldnt hibernate. except reboot. Also i get a side effect where my internet connection get "turned off" which is only mitigated by rebooting it.

I tried to add resume on mkinitcpio and add nvidia_drm=1 on my grub boot entry, but no avail.

Also if you put resume before crypt, you will have black screen unless you TTY through.

anonking1977 · 2025-04-09 19:55:06

apr 09 21:17:40 Archie systemd[1]: nvidia-hibernate.service: Deactivated successfully.
apr 09 21:17:40 Archie systemd[1]: Finished NVIDIA system hibernate actions.
apr 09 21:17:40 Archie systemd[1]: Starting System Hibernate...
apr 09 21:17:40 Archie systemd-sleep[523682]: User sessions remain unfrozen on explicit request ($SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0).
apr 09 21:17:40 Archie systemd-sleep[523682]: This is not recommended, and might result in unexpected behavior, particularly
apr 09 21:17:40 Archie systemd-sleep[523682]: in suspend-then-hibernate operations or setups with encrypted home directories.
apr 09 21:17:40 Archie systemd-sleep[523682]: Performing sleep operation 'hibernate'...
apr 09 21:17:40 Archie kernel: PM: hibernation: hibernation entry

those are my last files.

seth · 2025-04-09 21:32:47

seth wrote:

sudo journalctl -b -1 | curl -F 'file=@-' 0x0.st
for the previous boot and your entire mkinitcpio.conf responsible for that specific boot.

anonking1977 · 2025-04-10 04:37:13

Found the biggest issue:

Just remove the Modules from mkinitcpio.conf. idk if this is correct but it worked for me

seth · 2025-04-10 05:49:25

You're a true genius

WorMzy · 2025-06-04 14:01:33

Mod note: Closing this old thread to prevent further hijacking.

Arch Linux

#176 2025-01-17 13:06:17

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#177 2025-01-17 18:23:46

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#178 2025-01-22 01:34:52

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#179 2025-02-04 14:57:54

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#180 2025-02-24 18:10:04

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#181 2025-02-26 19:12:46

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#182 2025-02-27 08:25:50

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#183 2025-03-04 14:02:01

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#184 2025-03-04 14:27:29

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#185 2025-03-04 14:48:26

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#186 2025-03-04 14:55:50

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#187 2025-03-04 15:10:48

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#188 2025-03-04 17:05:08

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#189 2025-03-04 17:08:28

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#190 2025-04-09 12:20:17

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#191 2025-04-09 15:49:05

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#192 2025-04-09 18:17:34

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#193 2025-04-09 18:42:33

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#194 2025-04-09 19:51:34

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#195 2025-04-09 19:53:36

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#196 2025-04-09 19:55:06

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#197 2025-04-09 21:32:47

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#198 2025-04-10 04:37:13

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#199 2025-04-10 05:49:25

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#200 2025-06-04 14:01:33

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

Board footer