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

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 memory contents is written to the system’s root filesystem 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 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 maybe the statistics of my suspend/resume experiments is too insignificant, still.

Race conditions during resume?

I have checked old 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 during resume. In such a case the restart ofth edefault 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.