i used what i learned from this forum and checked my zypper lr -d and zypper se -si nvidia kernel-default output with ai, because it didnt quite match what i saw here and in this blogpost about how to install nvidia drivers that was already posted here: https://sndirsch.github.io/nvidia/2025/07/16/nvidia-drivers.html.
turned out, i had some duplicate repos and G06 all proprietary drivers, although G07 open kernel (and rest proprietary) is apparently the recommended way now.
i deleted the duplicate repos, migrated over to the correct G07 drivers and now everythings fine.
i remember having problems with nvidia drivers in the past. maybe i fumbled a bit too much and broke something then that only now appeared at the surfaceā¦maybe i shouldve installed the open kernel driver from the start but i have to admit i am still confused about the terminologyā¦like yeah, i want performance, so i should install proprietary drivers but i need the open kernel driver but theres a cuda repo but when i list my nvidia drivers with zypper i see repo-non-free and repo-oss drivers and then someone writes you shouldnt mix them but its fine if its kernel-default-devel and on and on and i felt i understood less and less, the more i read about it
anyway, thanks everyone and especially @Lioli7k , i hope my system will stay stable until i get myself an amd card in a few years
On my Slowroll machine, I have an NVidia RTX 4060 with the latest kernel-longterm, X11 and grub2-efi, and just yesterday I migrated from the nvidia-open-signed G07 drivers 595.48 (?) to 595.71. Everything works fine, including 3D games.
Before you rush and buy a new graphics card, you might want to try that combination of kernel-longterm and the latest consistent 595.71 drivers.
Tried kernel 7.0.5 and nvidia open G07 again. Didnāt worked. Black screen.
shifted to Kernel Longterm, and installed nvidia open G07 longterm. Working fine.
Hiya. Nvidia situation on Linux is complicated. Generally Nvidia driver consists of two parts:
User space tools and libraries (OpenGL, Vulkan and other libraies as well as configuration tools like Nvidia settings and nvidia-smi.)
Kernel modules (driver that talks to Nvidia GPU on hardware level.)
Each of those parts have a few options. They come either from Nvidia or from various open source projects.
User space tools have two options:
Nvidia (Proprietary. Meant to be used with one of Nvidia provided kernel modules flavor.)
Mesa (Open source. Used with Nouveau. Later on could be used with Nova.)
Kernel modules have four options:
Proprietary Nvidia (Historically used to be the default. Available for all Nvidia GPUs until RTX 50 series. RTX 50 series and newer are supported only by Nvidia open kernel modules.)
Nvidia open kernel modules (Open source friendly rewrite of older proprietary modules. Current default and should be preferred if available for your GPU. GTX 700 series or newer.)
Nouveau (Reverse engineered Nvidia driver by open source community. Available out of the box on all Linux distributions.)
Nova (Still in development. Nouveau successor for GTX 16/RTX 20 series and newer.)
Itās simplified but I hope it explains landscape well enough. In the current moment itās better to stick to proprietary Nvidia driver with Nvidia open kernel modules.
Iāve said it in the bugzilla but gonna post it here in more detail as well.
Out of curiosity Iāve checked change history of kernel-source at the Factory (here). There was an interesting change that wasnāt mentioned in the change logs when 7.0.1 was introduced. CONFIG_PREEMPT=y was set for kernel-default on x86_64 and some other architectures.
You can read online what preemption in Linux kernel is but hereās short version of it for the context. It allows kernel to interrupt a currently running task (even kernel code) and do something else. It is meant to reduce system latency.
Before that config option was set kernel (6.18.x and 6.19.x) was working in voluntary preemption mode. Meaning it could interrupt only at explicit points. After the change kernel (7.0.x) started working in full preemption mode by default. Meaning it could interrupt pretty much anywhere it wants, unless explicitly said otherwise.
This change conveniently became available in 20260428. Right where problems started. You could say that SUSE sets CONFIG_PREEMPT_DYNAMIC, so it can be easily switched back by adding preempt=voluntary kernel parameter in a bootloader config. But hereās the thing: SUSE also sets CONFIG_ARCH_HAS_PREEMPT_LAZY. And since commit 7dadeaa6e851e7d67733f3e24fc53ee107781d0f (also conveniently) introduced in upstream kernel 7.0, none and voluntary preemption modes are disabled when CONFIG_ARCH_HAS_PREEMPT_LAZY is set.
Just another voice along with the others - My Lenovo P15 Gen2 with NVIDIA TU117GLM (T1200 Laptop GPU) stopped working with āblack screen syndromeā following the kernel 7.0.1 change.
Updating through 7.0.5 continued issues.
Neither G06 nor G07 solved it.
I have reverted to kernel-longterm-6.18.28-1.1 with the nvidia-open-driver-G07-signed-kmp-longterm version 595.71.05 packages. All is working as expected.
Hiya. Iām working on it. Keep an eye on this thread once in a while. Iāll be posting my findings here as well as upcoming fixes and their timelines.
Before going to all that trouble ā¦ Just FYI ā¦ default kernel
windeath:/home/dart # zcat /proc/config.gz | grep -E 'CONFIG_PREEMPT'
CONFIG_PREEMPT_BUILD=y
CONFIG_PREEMPT=y
# CONFIG_PREEMPT_LAZY is not set
# CONFIG_PREEMPT_RT is not set
CONFIG_PREEMPT_COUNT=y
CONFIG_PREEMPTION=y
CONFIG_PREEMPT_DYNAMIC=y
CONFIG_PREEMPT_RCU=y
CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_PREEMPT_TRACER is not set
CONFIG_PREEMPTIRQ_DELAY_TEST=m
windeath:/home/dart # cat /proc/version
Linux version 7.0.5-1-default (geeko@buildhost) (gcc (SUSE Linux) 15.2.1 20260202, GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.45.0.20251103-3) #1 SMP PREEMPT_DYNAMIC Fri May 8 09:22:21 UTC 2026 (77ae3c4)
CONFIG_PREEMPT_BUILD=y
CONFIG_ARCH_HAS_PREEMPT_LAZY=y
CONFIG_PREEMPT=y
# CONFIG_PREEMPT_LAZY is not set
# CONFIG_PREEMPT_RT is not set
CONFIG_PREEMPT_COUNT=y
CONFIG_PREEMPTION=y
CONFIG_PREEMPT_DYNAMIC=y
CONFIG_PREEMPT_RCU=y
CONFIG_HAVE_PREEMPT_DYNAMIC=y
CONFIG_HAVE_PREEMPT_DYNAMIC_CALL=y
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_DRM_I915_PREEMPT_TIMEOUT=640
CONFIG_DRM_I915_PREEMPT_TIMEOUT_COMPUTE=7500
CONFIG_DRM_XE_PREEMPT_TIMEOUT=640000
CONFIG_DRM_XE_PREEMPT_TIMEOUT_MAX=10000000
CONFIG_DRM_XE_PREEMPT_TIMEOUT_MIN=1
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_PREEMPT_TRACER is not set
CONFIG_PREEMPTIRQ_DELAY_TEST=m
CONFIG_PREEMPT and CONFIG_ARCH_HAS_PREEMPT_LAZY are set and that hasnāt changed in upcoming 7.0.6.
i think i might have been a bit unclear: i have a stable running system at the moment. everything is good, i dont get error messages, i can reboot, sleep, shut down, 3d acceleration works, no artifacts, no weird display issues, resolution changes, all is good.
its just that i had 2 major problems (one was a few months ago and now this one) related to my graphics card, which cost me a lot of time debugging and at this point i expect this to continue to happen in irregular intervals. i am very happy snapper is there for the rescue but id rather not be in a situation to need it.
I have been daily driving tumbleweed for more than 2 years in a row now. It is quite stable (unless I do something stupid). Normally I get broken updates only once every few months. Aaaaand most of the time itās Nvidia thing. At the very least it got a lot better over the years. Night and day difference compared to what it used to be on Leap 42.2 back in 2017. And it will be getting better now that Nvidia is actually trying to do something about it. Maybe once Nova + NVK will be the default it wonāt be so annoying to deal with.
Iāve been running a Quadro T400, P400, RTX4000 and a Tesla P4 over the last few years, but Iāve only recently switched to the rpms, neither have given me any griefā¦ Some have been used as just offload, the P4 is compute only. But the T400 (Leap) and RTX 4000 as primary GPUās for over six monthsā¦ My first experience with Nvidia was in 2005 on S.uS.E 9.2/9.3
so, you are like john wick of nvidia drivers slicing thru all those updates.
I am on tumbleweed for 4 months. Had initial troubles with Nvidia driver packages mismatch. Found a way thanks to advice on this forum. Going smooth, and then this new problem hits. Hope that this is a kernel 7.0 issue, and once this sorted out, it will be fine atleast till kernel 8.0
By creating a systemd service to run nvidia-smi --gpu-reset @ Lioli7k I get a usable display eventually. This is just a workaround and itās not pretty but it does seem to work and allows me to use the 7.0.5 kernel with the 595.71.05 Nvidia driver.
slicing thru all those updates.