Some months ago I have written a post about a Nvidia option, which at that time helped to overcome a problem with a suspend-to-RAM [leading to a deep S3 sleep state] and a later incomplete resume operation from the S3 state to the original desktop session. The setting “nvidia_modeset vblank_sem_control=0” at least remedied a result which had been described by many users of different Linux flavors: The resume process ended up in a black screen with only a mouse cursor being visible. This situation was difficult to control – and typically one had to reboot the system.
In my experience things have changed a bit since the named post. Therefore, I give a brief summary of other settings below. These settings appear to support a relatively problem-free suspend-to-ram and resume operations on my Leap 15.6 system with my X11-based KDE Plasma a newer Nvidia driver of version 580.
Card, driver, services, grub_cmdline
I describe the settings for just one of my systems. The board is an older ASRock Z170 extreme+. The Nvidia card is a 4060 TI. My present driver is the proprietary Nvidia driver of version 580.105.08. It was installed from the usual repository. In particular the The RPM “nvidia-driver-G06-kmp-default” is installed.
Note: I have not checked whether things work on other systems and with Wayland, yet.
The default grub cmdline contains the parameter setting
nvidia-drm.modeset=1
The services
- nvidia-suspend.service
- nvidia-hibernate.service
- nvidia-resume.service
- nvidia-persistenced.service
- nvidia-powerd.service
are all enabled.
Nvidia configuration settings
In the directory “/etc/modprobe.d”, I have a file 50-nvidia.conf”, which contains the following option
options nouveau modeset=0
options nvidia NVreg_DeviceFileUID=0
options nvidia NVreg_DeviceFileGID=33
options nvidia NVreg_DeviceFileMode=0660
options nvidia NVreg_TemporaryFilePath=/var/tmp
options nvidia NVreg_EnableS0ixPowerManagement=1
options nvidia NVreg_PreserveVideoMemoryAllocations=1
options nvidia-drm modeset=1
#
options nvidia_modeset vblank_sem_control=0
Dependency on other things – like the resume-button and the sleep-time
I usually start suspending to RAM by options offered on the KDE Plasma desktop. But things work also from the command line. My ASRock-board shows that (video) memory contents is written to the system’s root filesystem (see option ) by indicating a respective storage-activity ahead of reaching the S3 state. When the deep suspend state S3 is reached the power button starts blinking.
The default keyboard-button for triggering a resume from sleep is the “blank” key. Using the keyboard to trigger a resume operation seems to work flawlessly so far. I get to the Plasma lock/login-screen for my previously running KDE session, which is restored in the state before the suspend-process – with all interrupted processes running again. Independent of the duration of the sleep time. Logs show that a time jump is recognized and that the system adapts to it.
However and notably:
Resume does not work always by pressing the power button on my case briefly. Actually, pressing the power button shortly after a long sleep time >≈ 15 minutes sometimes leads to a resume that ends up in a SDDM login-screen for a new KDE Plasma session. The logs then show that the old Plasma session could not be restored due to some error (see below). The system then obviously turns into workaround: It forgets the old KDE-session, restarts into the default graphical target and starts SDDM for a new graphical user session.
This strange behavior does not seem to happen when pressing the default keyboard button to trigger a resume operation. I cannot explain this – but it may be specific for my board and its settings. But that the statistics of my suspend/resume experiments may be too insignificant, still.
Race conditions during resume?
I have checked older logs and found that some resume processes have led to a situation were the X11-session appeared to be broken for certain starting applications as pulseaudio and gkrellm. This may be the result of race conditions between X11-restoration and processes requiring an X11-connection already during resume. In such a case the restart of the default graphical target happened. I can not yet exclude that such problems may still be lurking in the background. The number of my suspend/resume tests with varying sleep time durations may have been to small, yet, to detect such events.
Conclusion
The suspend/resume behavior on Leap-systems obviously changes depending on kernel and Nvidia’s driver versions. Presently, I have reached a relatively stable status regarding suspend-to-RAM and resume for KDE Plasma on a X11-basis. I hope this post helps some readers who experience instability problems with suspend/resume on Leap systems with Nvidia graphics cards.