Having issues recently with sleep and screen locking which seem related to Nvidia drivers. From 550 on, waking up from sleep no longer works and only goes to a black screen. Only way to get back is ctrl+alt+f1 and force a reboot.
Additionally if my machine automatically locks the screen, it can take a few minutes before a login field appears. Will sit stuck on the lock splash screen. However oddly if I manually lock my screen, its fine.
Currently on Nvidia 570.133.07. Doing a snapper rollback to 550.144.03 allows screen locking to work again, but there are many updates since then.
Is there a known fix for latest drivers? If not what is the correct process to roll back just the Nvidia drivers and keep all the other system updates in place?
The Nvidia repos are in an inconsitent state atm. Also for Leap. Not all packages have the same version (see bugreport).
You can simply downgrade the drivers if you want. E.g via YaST Software. Click on the versions tab of a package. Select the former version. Do this for all G06 packages. Apply.
Thanks will give that a try. Any idea what package might be causing the sleep issue? From what I can tell all the G06 packages are at the same 570 version.
I don’t know if it’s the correct way, but I deinstalled the 570 driver and reinstalled the RPMS for the last the 550 driver, then used zypper to lock the driver, the kernel and vmware (because vmware is often aligned with the kernel). Since then I’ve kept the dups rolling. I will release the locks when I want to give the new driver a try.
zypper al kernel-de* nvidia*G06* virtualbox*
I guess a simpler approach would be to roll back to the last working 550, apply the same locks and then roll forward.
Rolling back to 550.144.03 version seems to fix the locking issues. However, I was unable to simply roll back with Yast or Zypper. Had to find an old snapshot as this version of the Nvidia driver was failing on reinstall due to it missing in the repo. This is far from ideal, and am worried this issue will persist in any new Nvidia drivers.
I had a similar problems with the Nvidia 570 drivers on the lock and sleep (suspend to RAM) issues, black screen ctrl-alt-f1 would give me a terminal which allowed me to run shutdown -r now to reboot.
My card is a NVIDIA 2070 so a little older
and I’m running tumbleweed with all the latest updates, so NVIDIA is 570.133.07
blacklist nouveau
blacklist lbm-nouveau
#options nvidia-drm fbdev=1
options nvidia-drm modeset=1
#options nouveau modeset=0
#options nvidia NVreg_EnableGpuFirmware=0
options nvidia NVreg_PreserveVideoMemoryAllocations=1
options nvidia TemporaryFilePath="/var/tmp"
alias nouveau off
alias lbm-nouveau off
after you need to regenerate with
dracut --regenerate-all --force
This will show the parameters set for the Nvidia driver
Not sure this matters but I don’t have a 50-nvidia.conf file, however I do have 60-nvidia-default.conf and 90-nvidia-dracut-G05.conf
In 90-nvidia-dracut-G05.conf it has the following
# Omit the nvidia driver from the ramdisk, to avoid needing to regenerate
# the ramdisk on updates, and to ensure the power-management udev rules run
# on module load
omit_drivers+=" nvidia nvidia-drm nvidia-modeset nvidia-uvm bbswitch "
In 60-nvidia-default.conf it has the following
# Omit the nvidia driver from the ramdisk, to avoid needing to regenerate
# the ramdisk on updates, and to ensure the power-management udev rules run
# on module load
omit_drivers+=" nvidia nvidia-drm nvidia-modeset nvidia-uvm bbswitch "
Are these conflicting with each other? Sorry I don’t really know much about these.
so when the NVIDIA driver is loaded these parameters are used.
For you it looks like the NVIDIA driver loads after the kernel boots and is not included in the initial ram disk file. I think there are other ways of including NVIDIA parameters, maybe on the kernel command line.
So you could try NVreg_PreserveVideoMemoryAllocations=1 on the kernel command line. YAST->Boot Loader->Kernel Parameters and add this parameter there
Also the number in the conf name is used a priority, so 60-nvidia-default.conf would be process by dracut first then 90-nvidia-dracut-G05.conf as its building the initial ram disk file, as far as I know and in your case its omitting them for the ramdisk
I dup’ed everything to the latest, but then getting back from a screen lock isn’t guaranteed. Sometimes it works, sometimes there is a long delay, sometimes after a delay the panel is no longer responsive. (I don’t suspend, I just lock monitors.)
I think it may be this this bug: https://bugs.kde.org/show_bug.cgi?id=483094 - thes status of which doesn’t appear to have much priority: “With 82% of telemetry-using Plasma users on Wayland, and KWin now split between Wayland and X11, X11 is going into formal maintenance-only mode now, so I’m downgrading the priority of this X11-only bug.”
I went to backup and again restored to a working 550 driver and associated kernel.
I re-dup’ed from the 550 to the 570 driver and edited /etc/X11/Xorg.conf and set AllowGSYNCCompatible=off for my only gsync compatible monitor.
With just AllowGSYNCCompatible=off kwin fell over, so I also turned off , ForceCompositionPipeline, and ForceFullCompositionPipeline for both of my monitors (restarted/relogged in after each alteration). So the relevant Xorg.conf line is now:
So far, things seem OK. The fault was always a bit intermittent, occurring about 80-90% of the time, and varying in the degree to which things were broken. I’ll see how this goes for a couple of days.
After an extended period of lock of around 2 hours, a similar fault occurred. The lock screen started with just the background image, after a brief 10 second or so delay, the unlock prompt/inputs appeared and I was able to unlock the session. Then the panel (or kwin) fell over, but it was replaced by a new panel that appears to work. That’s better than before, where mostly the panel would not respond.
Perhaps the problem is not truly solved, but the odds are better. Maybe some other settings tweaks may help.
A follow-up. After a day or so, I’ve not had a failure that did not eventually recover, but on ulock, kwin/panel do quite often fall over, so the experience isn’t inspiring any confidence. I will probably roll back and stick with the 550 driver. I may even switch to the long term kernel.
