(NVIDIA, Wayland) No video signal when resuming from sleep

General system Kernel, boot, graphics & hardware
1

Hi, I’m pretty new to Linux and to reporting issues. If I need to send more info, let me know.

Running on Linux 6.6.48-1-LTS (tried 6.10.7-arch-1 as well) with KDE Plasma 6.1.4

Basically, I’ve tried to get my NVIDIA GTX 750 Ti GPU to work on Wayland, using the proprietary 560.53.03 drivers, which I’ve installed using nvidia-inst --no-dkms. I have set nvidia-drm modeset=1 in my GRUB entry and /etc/modprobe.d/nvidia-power-management.conf looks like this:

options nvidia NVreg_PreserveVideoMemoryAllocations=1 NVreg_TemporaryFilePath=/nvtmp
options nvidia-drm modeset=1
options nvidia NVreg_UsePageAttributeTable=1
options nvidia NVreg_RegistryDwords="OverrideMaxPerf=0x1"

Now, I can log into a Wayland session, and the performance is as good as it gets. However, when I run systemctl suspend (or use the Application Launcher’s sleep button), the system does suspend, but waking it up does not work as intended; The computer itself does wake up, and my mouse + keyboard’s lights do light up, but both of my monitors receive no signal. It’s not just a black screen, they are entirely off. It’s also not responding to keyboard input, cannot change TTY’s or anything. I have to hold down the power button to turn the computer off.

I’ve tried disabling the nvidia-resume.service, nvidia-suspend.service, nvidia-hibernate.service and nvidia-persistenced.services, but then the system would not go to sleep at all and throw me to the lock screen. If I enable those services, the issue described above happens.

I’ve also tried to plug the monitors out of my GPU and plug them back in, still no signal.

Tried looking for similar issues but nothing helped or they were different issues.

Here’s the output of systemctl -k -b -0 --boot=-1:
https://0x0.st/Xv7H.txt

And the output of inxi -Fxxc0z:
https://0x0.st/Xv78.txt

Thank you in advance.

2

this option "nvidia: unknown parameter ‘NVreg_PreserveVideoMemeoryAllocations’ ignored , is not accepted in version driver 5.60-3

3

Thank you for your answer.

I’ve tried removing options nvidia NVreg_PreserveVideoMemoryAllocations=1, leaving options nvidia NVreg_TemporaryFilePath=/nvtmp and removing the entire line, but it didn’t do anything. Same problem.

I ran sudo dracut --hostonly --no-hostonly-cmdline /boot/initramfs-linux.img --force and rebooted after each modification of the .conf file.
EDIT: I also ran grub-mkconfig right after dracut.

4

@sealovedmoon I have been experiencing the same issue. although it’s so inconsistent as to when it happens that I can even quite find a pattern - which is the reason why I haven’t posted about it. The experience is the exact same as yours in general, I have tried tweaking other power/sleep settings that gave me trouble before, such as having the displays turn off before the sleep time out. Also tried to disable the nvidia services and couldn’t go to sleep. I can tell it has resumed from sleep because if I removed an USB device, I hear the notification sound, although that seems to stop after a few seconds (no further notifications if I do it to other things - like unplugging the monitor, which fixed a similar issue for me in the past).

Does your issue happen consistently, every time you go to sleep?

I have tried to look for anything related to sleep/suspend/wake in journalctl and couldn’t quite find anything relevant

options nvidia NVreg_PreserveVideoMemoryAllocations=1 NVreg_TemporaryFilePath=/var/tmp is the only line I have in /etc/modprobe.d/nvidia-power-management.conf btw

5

@dave_at_hal9000 Yes, the issue did happen consistently, every time the system resumed from sleep. I think I’ve managed to fix it by appending nvidia_drm.fbdev=1 to /etc/default/grub, in the “GRUB_CMDLINE_LINUX_DEFAULT=” line. The entire line looks like this:

GRUB_CMDLINE_LINUX_DEFAULT="nowatchdog nvme_load=YES loglevel=3 nomodeset nvidia-drm.modeset=1 nvidia_drm.fbdev=1"

I also only have nvidia-suspend.service enabled, with every other NVIDIA-related service disabled.

6

Just saw this now, thanks for letting me know. What does that actually do? I am just going to YOLO it and try, but I seriously need to learn more about all these GRUB_CMDLINE_LINUX_DEFAULT parameters. I was messing around with some while trying to do PCI passthrough, but I have to admit I haven’t done much research and was just following along. For this particular issue, since it was surprisingly random, I have just been hoping a random update would make it go away lol

Thanks! I will report back if that solves things for me !

7

Well, to be entirely honest, I am not really sure myself. But from what I’ve read on the Arch wiki, nvidia_drm.fbdev=1 tells the kernel to use the NVIDIA driver’s framebuffer as opposed to relying on efifb or vesafb.
https://wiki.archlinux.org/title/NVIDIA#DRM_kernel_mode_setting

A side note I should have probably mentioned earlier (but haven’t since I thought it might only happen on my hardware) is TTYs are not rendering with fbdev=1. You can still type in them but the screens are off… so, you kind of have to choose if you want to be able to resume your system from sleep, or have functional TTYs. Once you try enabling it, could you report if they are blank for you as well?

8

Huh, I always try to switch to TTY and see nothing, but I wonder now if maybe it’s actually functional - the screen is not just blank per se, it’s not receiving any signal from GPU. Now that mention it, next time this happens I am going to try something on the TTY that would have an effect I can see - to confirm whether the TTY is active and I am not just seeing it (like sudo reboot). I suspect it’s the same case, since I still hear the notification sounds of plugging/unplugging devices while having no signal - so the plasma session is there and alive…

Since in my settings I have the power button configured to go to sleep, i have also tried to press that to see if it would go to sleep and I could wake up again, but it doesn’t work.

I haven’t had the problem in a little while and just got it today again, which prompted me to come check on the thread.

I am changing my grub from my current value of

GRUB_CMDLINE_LINUX_DEFAULT="nowatchdog nvme_load=YES nvidia-drm.modeset=1 loglevel=3

to your suggested

GRUB_CMDLINE_LINUX_DEFAULT="nowatchdog nvme_load=YES loglevel=3 nomodeset nvidia-drm.modeset=1 nvidia_drm.fbdev=1"

and see if it makes any difference. I will set a reminder for a week so I don;t forget to update you here if the probably doesn’t come back - since it’s been a bit random for me.

9

PS.: In my response I was referring to the TTY while the problem is occurring - but as to your question, I updated my grub to your same parameters, and while in normal operation, I am able to switch to TTY normally. I will update if the problem still occurs, or after a week if i don;t see it again

10

PSS.: Here’s the current status of my NVIDIA services

systemctl status nvidia-hibernate.service nvidia-persistenced.service nvidia-powerd.service nvidia-resume.service nvidia-suspend.service                                                                                                                                                                                                                                             

○ nvidia-hibernate.service - NVIDIA system hibernate actions
     Loaded: loaded (/usr/lib/systemd/system/nvidia-hibernate.service; enabled; preset: disabled)
     Active: inactive (dead)

○ nvidia-persistenced.service - NVIDIA Persistence Daemon
     Loaded: loaded (/usr/lib/systemd/system/nvidia-persistenced.service; disabled; preset: disabled)
     Active: inactive (dead)

○ nvidia-powerd.service
     Loaded: masked (Reason: Unit nvidia-powerd.service is masked.)
     Active: inactive (dead)

○ nvidia-resume.service - NVIDIA system resume actions
     Loaded: loaded (/usr/lib/systemd/system/nvidia-resume.service; enabled; preset: disabled)
     Active: inactive (dead)

○ nvidia-suspend.service - NVIDIA system suspend actions
     Loaded: loaded (/usr/lib/systemd/system/nvidia-suspend.service; enabled; preset: disabled)
     Active: inactive (dead)