Leap 15.6, Nvidia driver 580 – resume from S3 deep sleep state after suspend to RAM

Some months ago I have written a post about a Nvidia option, which at that time seemed to help to overcome problems with a suspend to deep S3 sleep state [Suspend to RAM] and a flawless resume operation from the S3 state.

In my experience things have changed a bit since the named post. Therefore, I give a brief summary of other settings which appear to support a relatively problem-free suspend-to-ram and resume operations on my Leap 15.6 system with KDE Plasma, X11 and a newer Nvidia driver.

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.95.05. It was installed from the usual repository. In particular the The RPM “nvidia-driver-G06-kmp-default” is installed. 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

blacklist nouveau
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 start suspending to RAM by command options offered on the KDE Plasma desktop. My ASRock-board shows that memory contents is written to the harddisk by indicating a respective SSD-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. Usually, I get to the Plasma lock/login-screen for my running KDE session, which is restored in the state before suspend – 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 sleep time >≈ 15 minutes often 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. 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 happen when pressing the default keyboard button to trigger a resume operation.

Conclusion

The suspend/resume behavior on Leap-systems changes depending on kernel and Nvidia’s driver versions. Presently, I have fortunately 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 problems with suspend/resume on Leap systems with Nvidia graphics cards.

 

Leap 15.6, Nvidia-driver – problems due to dependency on original kernel-default-devel package

After some updates of Opensuse’s Leap 15.6 systems via a variety of repositories (including the SLES 15.6 repo as the main and leading repository), one of my installed packages was removed. I am talking about a very central one, namely “kernel-default-devel version 6.4.0-160600.21.3-x86_64”. (It can be found in the main repository of the 15.6 distribution.) This was in so far reasonable as I have no longer any respective kernel installed. All used kernels are of version “6.4.0-156000.23.xxx”.

However, the removal of the old kernel-default-devel package caused difficulties with the Nvidia drivers in Opensuse’s respective repositories. The installation and compilation of the required diver module delivered by package “nvidia-driver-G06-kmp-default” would fail. It requires the original kernel-default-devel version 6.4.0-150600.21. As a consequence on the affected systems the Nvidia driver could no longer be loaded.

A supplemental installation of the original kernel-default-devel package (coming with the distribution) remedied the problems. Hope this helps others who experience similar problems during system updates.

 

Upgrade from Leap 15.3 over 15.4, 15.5 up to Leap 15.6 – problems with the named service

Sometimes one takes a challenge with Linux. During my stay in Norway I wanted to find out whether one could bring a really old server system (regarding HW) to the latest Leap version of Opensuse. Such an old system can still serve valuable purposes – as testing complex configurations of server components, using it as an extended IDS/Firewall-system, etc. In my case I was fortunate as the real problem occurred with SW and not HW.

Regarding HW my concerns related to an old Nvidia GT 710. The advantage of this card was/is that it is passively cooled and provides enough power for using both a present KDE or Gnome desktop – if necessary or useful. I was lucky to find that the present G05 Nvidia drivers support this card.

Somewhat unexpectedly, real problems occurred with an installed named-service at the upgrade from 15.3 to Leap 15.4 – and again when upgrading from 15.5 to 15.6. While you can find many complaints on the Internet, I did not find a solution that covered all my problem. Therefore, I want to give Linux users or administrators who experience similar problems some hints.

Continue reading

Leap 15.6, Nvidia driver 570 – resume from suspend to RAM not working / workaround

Hint: After some experiments and further Internet digging, this post was rewritten and supplemented on the 5th of March, 2025. Sorry for any inconvenience.
—–

Recently, I have upgraded Opensuse Leap to version 15.6 on 5 PC-systems – all with (different) Nvidia graphic cards. I use KDE/Plasma on all these systems.

My daily working system is equipped with a 4060 TI Nvidia card. Nvidia drivers of version 570.124.06-1 on this particular system came from the Nvidia CUDA repository for Opensuse system at

https://developer.download.nvidia.com/ compute/ cuda/ repos/ opensuse15/ x86_64.

I sadly must say that the named particular driver, but also the present Nvidia drivers of version 570.86.16 on other systems, are at least in their corporation with the Linux kernel (6.4.0) and other components of the present Leap 15.6, unreliable or even buggy (for KDE/Plasma):

The resume process from “Suspend to RAM” does not work reliably on any of the systems.

Continue reading

Leap 15.6 – upgrade from Leap 15.5 on laptop with Optimus architecture

The last 4 months I was primarily occupied with physics. I got a bit sloppy regarding upgrades of my Linux systems. An upgrade of an rather old laptop to Leap 15.6 was overdue. This laptop had an Optimus configuration: To display graphics one can use either the dedicated Nvidia card or a CPU-integrated Intel graphics or both via an “offload” option for certain applications.

General steps to perform the upgrade

I just list up some elementary steps for the upgrade of an Opensuse Leap system – without going into details or potential error handling:

Step 1: Make a backup of the present installation
You can, for example, create images of the partitions or LVM volumes that contain your Leap-installation and transfer them to an external disk. Details depend of course on whether and how you have distributed system files over partitions or (LVM) volumes. In the simple case of just one partition, you may simply boot a rescue system, mount an external disk to /mnt and then use the “dd”-command;

# dd status=progress if=/dev/YOUR_PARTITION of=/mnt/bup_leap155.img  bs=4M 

Step 2: Update the installed packages of the present Leap installation
Perform an update of (all) installed packages – if newer versions are available. Check that your system runs flawlessly afterwards.

Step 3: Change the addresses of repositories to use the ${releasever} variable
You can e.g. use YaST to change the release number in the definition of your repositories’ addresses to the variable ${releasever}. The name of the SLES repository may then look like “https://download.opensuse.org/update/leap/${releasever}/sle/”.

Continue reading