Author Archives: eremo

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

Posted on by

Some months ago I wrote a post about a Nvidia option, which at that time helped to overcome a specific problem with a suspend-to-RAM [leading to a deep S3 sleep state] action and a following 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 relatively stable 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. However, though not leading to black screens any more, the resume process will not always restore the interrupted KDE/Plasma session. Notably, after a series of extended tests the suspend/resume processes seem to work significantly more stable with Wayland than with X11.

Note, 11/08/25: I had to change this post after some more systematic tests. While I could confirm my general impression that driver Nvidia 580.105 has brought more stability to resume processes from deep S3 sleep, on a X11 based KDE/Plasma desktop, resume processes do fail sometimes – in 20%-30% of the cases. Probably due to race conditions during the restoration of the interrupted KDE/Plasma-session (see below). This did not happen in a series of tests with different sleep time intervals for a Plasma desktop based on Wayland.

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 Nvidia 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. KDE is of version 5.115, Plasma of version 5.27, t5 of version 5.15.12.

Note: I have not checked whether things work on other systems or with Gnome based desktops, 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

Resume-buttons

I usually start suspending to RAM by options offered on the KDE Plasma desktop. But things work also from the command line or with automatic invocation after some idle time of the desktop. 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. I can also use the power button on my PC case to start the resume process. If the resume process leads to the old KDE/Plasma session – which it does in more than 60% of the cases with X11 – this session 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.

Results after a series of tests on X11 and Wayland based KDE Plasma desktop

In contrast to previous versions of this post, I have now investigated the behavior of the resume processes a bit more systematically, both for X11 and Wayland. For each of the platforms, I have tested the success of suspend/resume processes 15 to 20 times – with growing duration of the sleep interval between 5 minutes up to 40 minutes. The tests also varied with respect to the triggering of the suspend action, regarding both direct user action or, alternatively, an automatic start of a suspend process after some defined idle time. In the latter case a lock/login screen was invoked some minutes before suspend started. (You find respective options in KDE-5’s “systemsettings5”.)

X11-based KDE/Plasma
In the case of X11 a return to the interrupted KDE Plasma session fails in around 30% of the cases. In such cases the resume process 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 a workaround: It forgets the old KDE-session, restarts into the default graphical target and starts SDDM for a new graphical user session. So, the problem with a blank screen and only the mouse cursor blinking appears to have gone (maybe due to the settings “nvidia_modeset vblank_sem_control=0” or due to other improvements; this still has to be checked).

Note, 11/08/25: A previously assumed dependency of the resume success on using the power button or, alternatively, the keyboard to start the resume operation has disappeared after a larger number of tests. There still seems to be a dependency on the duration of the sleep time.

This result means that users of KDE/Plasma should take care of saving all their work before leaving their KDE/plasma desktop unattended with settings that automatically trigger suspend after a defined idle time.

Wayland-based KDE/Plasma
Let me first mention that Wayland meanwhile works really well for the wide range of applications I regularly use. For all the 20 times I tested suspend/resume on Wayland, each trial ended in a successful and complete restoration of the interrupted KDE/Plasma session (which could be entered via login to my KDE session lock-screen).

Race conditions during resume for X11-based KDE/Plasma desktop?

Afterwards, I have checked the logs for X11 and found that the failed 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.

Conclusion

The suspend/resume behavior on Leap-systems obviously changes depending on kernel and Nvidia’s driver versions. Presently and on Leap 15.6 systems, we have only reached a relatively stable status regarding suspend-to-RAM and resume for KDE Plasma on a X11-basis: In more than 60% of the cases, the interrupted KDE/Plasma session is fully restored. In other cases I, at least, did not experience blank screens, but a return to the SDDM login-screen for a new desktop session. X11 users should therefore save all their work before leaving the desktop.

The good news is that suspend/resume appears to work flawlessly with Wayland (at least on my conservative Leap system).

I hope this post helps some readers who experience instability 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

Posted on by

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.

 

KDE Plasma users – reconfigure your desktop from scratch when you experience startup delays after system upgrades

Posted on by

This post is basically for KDE Plasma users on Linux systems which are not based on rolling releases, but which get upgraded in the course of defined upgrade cycles of the distribution. It is a kind of reminder about a rather trivial point when you upgrade your Linux system or when someone else has done this for you:

  • It may sometimes be worth the effort to rebuild and reconfigure your KDE Plasma desktop after your Linux OS has been upgraded.

A full upgrade of a modern Linux system comprises the upgrade of very different components. In most cases a change to a newer version of your preferred desktop environment is part of the packet upgrades. Regarding the evolution of KDE/Plasma during the last 20 years, I have several times experienced that the desktop may exhibit problems after such an upgrade. In a few cases the desktop itself and its configuration would struggle with problems, sometimes a certain application or plasmoid had deficits. Such deficits have most often affected the performance or presentation of only the application on the desktop, but sometimes the overall desktop performance was hampered.

Startup times for standard Linux systems are pretty fast these days – including the start of a graphical desktop session. Even on a 12 years old laptop a KDE Plasma desktop based on X11 builds up within 3 secs after passing login credentials – even with reconstructing the status of multiple applications you left open at the end of your last KDE session. Part of the time may go into (Wifi) network access – and the establishment of complex firewall rules during network startup by networkmanager – dependent on your configuration. But under normal circumstances, establishing network connections by networkmanager should not be an obstacle for a fast general start of the graphical desktop.

Therefore, it should make you nervous when you find that starting a KDE Plasma session on a laptop takes around 10 to 20 secs. This was an experience I yesterday had on a system which had been upgraded to Opensuse Leap 15.6 some months ago. The user was frustrated about a long delay during KDE startup – which he could prove by excerpts of logged system messages. Unfortunately, neither the system logs nor the X11 logs indicated clearly what the reason was. In my opinion, this was an indication of some problematic configuration. Even if the KDE desktop appeared to work without problems after its long startup phase. Some app or plasmoid could have waited during the start of the desktop session for a rather long period for a timeout.

I could help my acquaintance. The question who has caused the glitch, the user or the OS provider, most often is relatively unproductive and fruitless. As long as there is no indication of a hacker’s manipulation … Leaving the possibility of a hacker’s interference aside, we first of all want to reconstruct a working graphical environment. If we find the culprit for the problems on our way – the better it is. Nevertheless, for important system exposed for whatever reason to unfriendly attackers, I would recommend to make forensic copies of the system first. Never ever think, Linux is a kind of barrier for experienced hackers …

This post, therefore, is about a possible solution under best circumstances – namely about a systematic reconstruction of your KDE desktop, its layout, plasmoids and applications to avoid configuration “errors” you may have carried around with you since the last or even since some older upgrade.

Continue reading →

S3Dlib, Matplotlib, 3D rendering – spheres in front of a surface

Posted on by

Recently, I needed a certain type of 3D-illustration for a post series about cosmology. I wanted to show a 2-dimensional manifold above a mesh grid with respective coordinate lines on the surface. In front of the surface I wanted to place some opaque spheres. Such illustrations are often used in physics to demonstrate the effect of some objects on a physical quantity – e.g. of spherical bodies on the gravitational potential or on a component of the metric tensor of space-time.

The simple problem to get a correct rendering of objects along a defined line of view upon a 3D scene posed a problem for Matplotlib’s 3D renderer for multiple objects in a 3D axis frame (created by ax = plt.axes(projection=’3d’)). The occlusion of objects was displayed wrongly for most view ports and viewing angles.

In this post, I briefly want to outline how this problem can be solved with the help of S3Dlib. As a beginner regarding the use of S3Dlib, I had to overcome some problems there, too. So, this small exercise with some options of S3Dlib might be interesting for some readers which want to use Python and Matplotlib for rendering simple 3D scenes.

The following plot shows what I wanted to achieve:

Correct rendering of two spheres in front of a surface by S3Dlib
Correct rendering of two spheres in front of a surface by S3Dlib
Continue reading →

Bye, bye Opera … welcome Vivaldi

Posted on by

These are hard times regarding politics and IT. Present developments, in particular in the USA, in China and Russia have an indirect or direct impact on various types of IT-components – concerning e.g. production sites, quality, tariffs and prices, data control, digital privacy. We in Europe who have supported Opensource and Opensource-based applications for decades, can – in my opinion – not ignore tendencies both of dictatorial regimes and capitalistic tech-giants to control the future of IT in general, the production of IT-related products and the efforts to control and analyze more and more of user-generated traffic. Be it for the surveillance and control of citizens or to earn money via analyzing user profiles and spamming them indirectly with advertisement. Even more concerning is the growing power of a handful of companies and institutions over the development and the ultimate direction of AI. The risks in all of these sectors to harm digital privacy (aside of the un-social media) are growing.

But we Europeans should also have an eye on who invests in what – and whether such investments come from countries which support aggressors against European countries or the EU. We sometimes need to take a clear position. Better late than never as in my case.

Continue reading →