You are not logged in.
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.
Offline
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).
Offline
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)
Offline
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?
Offline
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.
Offline
@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)
Offline
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
Offline
@seth Can you point me to the patches required?
I encountered some weird bugs after core packages update. Seems I've no choice.
Offline
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
Offline
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
Offline
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)
Offline
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.
Offline
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
Offline
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.
Offline