Black screen on Nvidia after updating to 20260428

English Install/Boot/Login
,
622

minus -s does all that except the “proprietary” part … and I don’t disable glvnd … also use packman so …

623

@dart364 Likely no CPU PAT support… See Line 261;

https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/kernel-open/nvidia/nv-reg.h

Worth a read of the rest of the comments in the file…

624

Well it might default to 0 on my ancient machine … might be worth setting it to 0 on the newer ones to see if it makes a difference

625

Had to resort to good ol’ duct tape but I finally managed to build a kernel with voluntary preemtion mode. For better or worse it had no effect. Seems like there’s logical bug somewhere down graphics initialization path. Probably during switching from efidrm to nvidia-drm. Time to read how graphics work on Linux under the hood.

5 Likes
626

Hats of to you Lioli7k. Yo have tried so many different things.

5 Likes
627

Thanks for trying that path! Would it be possible to add the temporary workaround (Black screen on Nvidia after updating to 20260428 - #469 by simonsan) to your #0 so people have a tiny update to this huge thread directly in the OP?

628

Unfortunately no. :frowning_face: I can not edit title or posts that are older than 10 minutes in this thread. So I’ll have to tell them or direct to your post every time.

629

I did, but none of them were fruitful unfortunately. At the very least I know where to look for it and I can read kernel’s C code without issues. So I’ll find it sooner or later. Just unsure if I’m knowledgeable enough to patch C code myself.

630

Well I commented out the uvm portion of my 90-nvidia-conf file and was greeted with a blackscreen and had to do initcall_blacklist=sysfb_init like everyone else. After uncommenting the lines one by one it turns out that these two lines are the ones that allow me to boot normally (and see boot messages). Time to look at the rest of the options and try some of those I guess

uvm_exp_gpu_cache_sysmem=1 \
uvm_exp_gpu_cache_peermem=1 \
3 Likes
631

I’ve added a staff notice at the top of the topic that has a link to the workaround. We don’t usually do this, but as there are over 600 posts in this topic, this will hopefully help people find it.

2 Likes
632

Thank you. Is there a limit for pins? LTS kernel workaround is harder to do, but it’s probably a better workaround since it doesn’t mess FDE up (typing password blindly is no fun) and doesn’t hide error messages on boot. So it should be pinned too if possible. It’s mentioned here.

633

We can only do one staff notice, but I can add an additional link to the notice, and will do that. It’s not really a ‘pinned’ post (that’s not functionality we have AFAIK), just a staff notice for the topic.

2 Likes
634

Thank you, that works too. This thread is difficult to navigate as is…

1 Like
635

Adding these modprobe lines seems to resolve the issue for me also using nvidia-open-driver-G07-signed-kmp-default-595.71.05_k7.0.9_1-2.6. Boot proceeds normally without blanking out to a blue screen until nvidia-reset service is called which I’ve disabled.

636

Sorry, I spoke too soon because after another reboot the issue is back. So it’s hard to tell if it had any effect because the issue seems to be intermittent on my machine although the majority of the time it breaks.

637

No effect on my side.

638

I am reading every post every day.

Today I was go to make the .service file, but at last, I didn’t do anything. I am boring of do tries with 7.0.1, 7.0.3, 7.0.5 and 7.0.7. The parameter in the kernel (the initcall) didn’t do nothing too 1 week ago.

I locked my kernel in 6.19.12 and I’ll wait to read a magical solution that works (not the initcall or make the .service) or read that someone fix the kernel or Nvidia fixes the driver.

Regards and I’ll continue reading

1 Like
639

Today I saw a ray of hope.

New Nvidia driver 610.43.02.

So, I unlocked kernel, update to 7.0.9, install 610.43.02 and rebooted.

SDDM appears (great!) but incredibly slowly. So, if SDDM goes slowly, KDE Plasma will go worst.

Instead to enter KDE Plasma, I rebooted and add to the parameters kernel in Grub initcall_blacklist=sysfb_init. SDDM appears fast (and I have TTY and the boot messages available) but when I enter in KDE Plasma, Kwin crashed.
I started a game in Steam and Kwin crashed again.

Note: Seems that the 610.43.02 have problems with some Wayland compositors and seems that KDE Plasma 6.7 will fix this. Devs are working to fix 6.6:

So… “I’ll try with the 595.71.05 again but with the kernel parameter”, said me.

I did it the process and all goes well (thanks to initcall_blacklist=sysfb_init). But before of 7.0.9 this parameter don’t worked for me.

Well, now I have fixed my issue. Thanks to every post of this thread.

Regards

640

I’m glad this is working for Krovikan.

I have had the same issue; with constant Kwin crashes and video issues including on Kernel 7.0.9-1.1, and NVIDIA drivers 580.159.03-54.1.

Adding initcall_blacklist=sysfb_initdoes work as a work-around for KDE stability and apparent normal driver use, but with issues around Plymouth sometimes giving a green screen (but booting without issue).

I personally am not daring to do a “zypper dup” until the cause and the solution are known?

I note mention of an issue with Wayland compositors and KDE, but I am using X11 with the same problems, so this may not be the same issue? And people in this thread mention both Gnome and KDE. This seems to be more fundamentally a Kernel 7 and NVIDIA Driver issue, and one that seems to specifically be affecting OpenSuSE?

641

If you are concerned I’d suggest installing the long term kernel as mentioned by other people in this thread or locking your current kernel packages along with the Nvidia ones because you may not be updating for a while otherwise.