510.39.01 on 5.16.0 kernel green screen

Just tried 510.39.01 on 5.16.0 kernel. This is giving a green screen a few seconds after boot. The journal doesn’t have any info at all - and login manager can still be reached but this is a black screen with a mouse cursor.

Ryzen 9 5950x
NVIDIA GeForce RTX 3060 Ti
Fedora Linux 35

Wayland or Xorg?
Please run nvidia-bug-report.sh as root and attach the resulting nvidia-bug-report.log.gz file to your post.

I have a 5600X + 2080 + 5.16 + 510.39.01
I compiled from the Wayland git to resolve whatever was causing my issues; and renamed my xorg.conf file to xorg.conf.old for a fresh one to be autogenerated.
YMMV of course, I’m also on Ubuntu.
But hey. Worth a shot.

Of course once you are SSH’d in you would (per the git):

$ git clone https://gitlab.freedesktop.org/wayland/wayland
$ cd wayland
$ meson build/ 
$ ninja -C build/ install

Are you using the f36 5.16.0 kernel?

Well that’s the issue. Green screen on boot, remains until GDM starts which is black - can’t switch to TTY to get info as it hardlocks.

No info in journal history either sorry.

Yes, was testing it to see what improvement it made for ASUS GA401Q laptop.

The f36 kernel has removed the frame buffer and replaced it with simpledrm which isn’t compatible with nvidia



Uh… geez. Okay so where do we go from here? Anyone know if Nvidia intends to support DRM?

What kind of device is this, anyway? Hybrid graphics or nvidia only? Without knowing anything, in case of nvidia-only, I`d expect something named "simple"drm to use dumb buffers, does embedding the modules in initrd and setting nvidia-drm.modeset=1 change things? This should support drm dumb buffers.

Sorry, I seem to have been overworked. This was my desktop, not laptop.

In either case I don’t have time to debug this. I was hoping someone had bumped in to it or knew the cause - and that nvidia or fedora was fixing it.

Confirmed here, kernel-5.16.1-200.fc35.x86_64 does not work kernel-5.15.4-200.fc35.x86_64 does work. Green screen tried with modeset=1 or 0 same thing…

I had this issue in 5.15 also in the rc# release builds in Fedora…

RTX 3090 here

So, I can’t build 5.16.x currently since there is some issue with gcc (rawhide) cannot build Fedora 35 kernels on rawhide. I’m on hold with 5.15.x for now.

Nvidia, you know Intel is coming for you… do the right thing and just open the kernel driver, you can hide your secret sauce in a binary firmware.

We will drop the pci_request_regions call to avoid an interaction issue with SYSFB_SIMPLEFB, but it might be workaround a different way by the Fedora feature maintainer.
The update will be made available for Fedora rawhide users at the end of the week, (or get it from there)

See also nvidia-kmod/nvidia-kmod-pci-request-regions.patch at master · rpmfusion/nvidia-kmod · GitHub

1 Like

With kwizart’s patch and kernel option, there is a workaround solution you can try booting with: initcall_blacklist=simpledrm_platform_driver_init or fbcon=map:1. I tried the first and it worked.

Thanks to the Fedora Kernel folks for this workaround until there’s a proper fix.

I do think you need the patch also, but I haven’t tried without.

Patch apparently not required (from my own tests). I used the first option you provided.

Good day!

Sorry for jumping in on this thread, not having exactly the same issue.

I’m not on fedora, but on Linux Mint. And not yet using the v.510 nvidia driver, but v.470.

I do build my custom kernel for quite some time.
Today I built kernel v. 5.15.17 and was presented with questions during “make oldconfig” about the new simple fb/drm options. I did choose to say “yes” and also to mark the old framebuffer drivers as fallback.
I usually want to see the early boot messages, but booting with the new kernel, there was nothing until the display manager was up with the graphical login prompt.

So I’d like to kindly ask, if anybody here knows, what combination of kernel compile options have to be enabled/disabled to make the new simple drm thingy work? (of course I’m booting in EFI mode).

Thank you in advance!

The problem you describe (no text mode during boot, graphical desktop works just fine under the proprietary driver) sounds like you probably have the simplefb driver loaded without simpledrm. If you modprobe simpledrm you should see the text console return, BUT this will also generate a second DRM interface to your video card (use systool -c drm -p to see all of the active interfaces), which tends to cause Xorg to crash.

There’s technically no conflict between simpledrm and the proprietary NVidia driver, but the internal Xorg architecture doesn’t deal very gracefully with choosing the right DRM device, and will usually either generate a fatal error about failed modesetting, or else just segfault in xf86PlatformDeviceCheckBusID. In theory you can work around that with Option “kmsdev” in your xorg.conf, but I had uneven results. Wayland doesn’t seem to care whether you have both simpledrm and nvidia_drm loaded at the same time, but it has other limitations with the proprietary NVidia drivers.

Fortunately, you can always rmmod simpledrm (which will blank out the text consoles), run X with no issues, and then modprobe simpledrm again, and your text console will reappear exactly as you left it (since the data buffers are managed by simplefb; simpledrm is used only for modesetting). This is of course annoying, so you’ll probably have a better experience ditching simplefb/simpledrm and using either efifb (if booting UEFI) or vesafb for the console. Make sure you also disable “Mark VGA/VBE/EFI FB as generic system framebuffer” (CONFIG_SYSFB_SIMPLEFB), which lives under Drivers → Firmware Drivers in menuconfig rather than among the graphics driver section.

Summary of key kernel options:
CONFIG_DRM_SIMPLEDRM, CONFIG_FB_SIMPLEFB, and CONFIG_SYSFB_SIMPLEFB all unset (or at a minimum SYSFB_SIMPLEFB unset, and the simpledrm module manually unloaded or blacklisted)

Unfortunately, 5.15 and later kernels have simplefb, simpledrm ,and the SYSFB_SIMPLEFB pickup all enabled by default, and I would imagine most distributions ship their standard kernels that way, so NVidia users will have to manually fix this until Xorg (or the nvidia module) gets smarter about checking multiple DRM devices.