Nvidia driver isn't compatible with simpledrm so boot output and TTYs are blank

Hi,

I run Fedora 37 and using nvidia proprietary drivers I cannot access any of my TTYs, and the kernel out during boot (disabling rghb quiet in grub) is blank once the driver gets loaded. As far as I can tell, this was caused by a change in Fedora 36 where fbdev (drivers?) were replaced with CONFIG_DRM and CONFIG_SYSFB_SIMPLEFB. On my gentoo install running the latest nvidia drivers, I can run CONFIG_FB_SIMPLE on my kernel (which I can’t on Fedora because it’s prebuilt) without an issue and I can access my TTYs and watch the boot process on my RTX3070.

There was a bug raised against Fedora for this, where a workaround was implemented: 2071209 – Laptop display is not turning on with simpledrm driver in kernel and Nvidia driver - but the underlying issue is that the nvidia driver currently relies on having the EFIFB driver loaded, and isn’t compatible with simpledrm, so it would be nice if nvidia were to add support for using the simpledrm framebuffer instead.

The workaround for Fedora >= 36 is to have nvidia-drm.modeset=1 be added to the kernel command line (e.g. edit GRUB_CMDLINE_LINUX in /etc/default/grub and regenerate grub config) which will trigger the workaround and should allow everything to work as it did before.

Unfortunately, I already have nvidia-drm.modeset=1 to have Wayland work. My motherboard is old enough that it doesn’t come with an EFI, so what can I do now?

Ah right - well - the patch linked from the bugzilla was supposed to also use the VESAFB when not in UEFI mode, but I’m guessing something there doesn’t quite work for you - not sure if anyone tested the non-UEFI boot mode I’m afraid. I suggest replying to that bugzilla to see what other info you could provide to help understand what’s going on for you.

On my gentoo install running the latest nvidia drivers, I can run CONFIG_FB_SIMPLE on my kernel (which I can’t on Fedora because it’s prebuilt) without an issue and I can access my TTYs and watch the boot process on my RTX3070.

can you explain a little more this?

is kernel 6.x?

greetings

EDIT: apply this patch as “upported” to kernel 6 and add nvidia-drm.modeset=1 to kernel commandline. not works for me :(

diff --git a/drivers/firmware/sysfb.c b/drivers/firmware/sysfb.c
index 2bfbb05f7d896912712679b9999060a2b04e4685..a504f7234f35289fa8b577f10b570ce25dbf28f3 100644
--- a/drivers/firmware/sysfb.c
+++ b/drivers/firmware/sysfb.c
@@ -34,6 +34,22 @@
 #include <linux/screen_info.h>
 #include <linux/sysfb.h>
 
+static int skip_simpledrm;
+
+static int __init simpledrm_disable(char *opt)
+{
+	if (!opt)
+                return -EINVAL;
+
+	get_option(&opt, &skip_simpledrm);
+
+	if (skip_simpledrm)
+		pr_info("The simpledrm driver will not be probed\n");
+
+	return 0;
+}
+early_param("nvidia-drm.modeset", simpledrm_disable);
+
 static __init int sysfb_init(void)
 {
 	struct screen_info *si = &screen_info;
@@ -45,7 +61,7 @@ static __init int sysfb_init(void)
 
 	/* try to create a simple-framebuffer device */
 	compatible = sysfb_parse_mode(si, &mode);
-	if (compatible) {
+	if (compatible && !skip_simpledrm) {
 		pd = sysfb_create_simplefb(si, &mode);
 		if (!IS_ERR(pd))
 			goto unlock_mutex;

(CONFIG_DRM_SIMPLEDRM=y, CONFIG_FB_VESA=y and CONFIG_FB_EFI=y is enabled by default in my kernel (based/used Archlinux package)

EDIT2:
ok. thansks to this Legacy framebuffer broken since 5.18.13 · Issue #341 · NVIDIA/open-gpu-kernel-modules · GitHub the TTY with nvidia and kernel6 is back!!

This issue has not yet been addressed by the nVidia driver and Arch Linux has dropped the patch preventing the simpledrm device as of kernel 6.12.

Boot text is missing, TTYs are unavailable, and attempting to switch to a TTY freezes the session.

See:

  • Arch Linux | Kernel 6.12.1
  • nVidia 565.57.01
  • Gnome-shell | Mutter 47.2

I’ve reproduced this issue with a fresh boot using nvidia_drm.modeset=1 nvidia_drm.fbdev=1 kernel parameters.

Generated and attached an nVidia bug report:

nvidia-bug-report-simpledrm-2024-12-03.log (16.3 MB)

These issues are still present with nVidia 565.77 driver.

The patch has been re-added to the Arch Linux kernel build as of 6.12.3 until this is fixed in the nVidia driver.

This issue is still present with the 570.86.16 Beta driver.

For older generation GPUs (<= Pascal), nvidia_drm.fbdev=0 kernel parameter is still required to have a functional TTY, display the full boot text, and avoid the “freezing” / black screen.

Also, nvidia_drm.modeset=1is still required as a kernel parameter to avoid the simpledrm device creation, used in combination with the patched Arch kernel.

EDIT: Cross-linking back to an extensive, related Arch GitLab issue for more details:

This issue remains unfixed with the nVidia 570.124.04 Production driver.

See description above.

This issue is still present with nVidia 570.133.07 Production Branch drivers.

Reproduce using nvidia_drm.modeset=1 nvidia_drm.fbdev=1 kernel parameters.

Console boot text is still missing after initrd, and system soft-freezes when attempting to access TTY.


Latest stack:
  • Arch Linux | Kernel 6.13.7
  • Gnome-shell | Mutter 48.0
  • Wayland (meson_options: xwayland=false, x11=false)
  • Gtk4 4.18.2
  • Mesa 25.0.2
  • vulkan-icd-loader 1.4.304
  • nVidia 570.133.07

Linking back to overall summary tracker:

1 Like

This issue is still present with nVidia 570.153.02 Production Branch drivers.

Reproduced using nvidia_drm.modeset=1 nvidia_drm.fbdev=1 kernel parameters.

  • Console boot text is still missing after initrd
  • System soft-freezes when attempting to access TTY.

Current stack:

  • kernel 6.14.7
  • gnome-shell 48.1 (Wayland)
  • mutter 48.2 (-Dxwayland=false -Dx11=false)

Unfortunately this bug is still present with the 575.57.08 New Feature Branch driver release.

  • kernel 6.14.7
  • gnome-shell 48.2 (Wayland)
  • mutter 48.3 (-Dxwayland=false -Dx11=false)
  • nVidia 575.57.08

Attaching a fresh bug report.

nvidia-bug-report.log.gz (1.0 MB)


I wasn’t able to reproduce your problem, but I also can’t tell from the bug report log exactly what your display configuration is (logging with Wayland is lacking compared to Xorg). Can you describe exactly how many and which kinds of monitors you have attached?

1 Like

Hi, thanks for taking a look at this.

The issue here is twofold:

#1) simpledrm framebuffer device incompatibility in coexisting with nVidia driver. Arch is still carrying a patch after many kernel releases going back at least to kernel 6.3.x, requiring all nVidia users to apply nvidia_drm.modeset=1 kernel parameter to inhibit the simplefb in early boot:

#2) nvidia_drm.fbdev=1 incompatibility with older generation nVidia GPUs (<=Pascal). Ever since fbdev=1 became the default… TTYs are not accesssible, Gnome soft-freezes, and any console boot text following the initial initramfs loading is missing/blank, presumably when the framebuffer handoff occurs.

My setup is two older standard 60hz monitors, one DP the other DVI, running off a GTX 1050Ti.

  • DVI: (DELL U2711): 1440x2560 @ 60 Hz (as 810x1440) in 27" [External]
  • DP: (PHL 328E1): 3840x2160 @ 60 Hz (as 3072x1728) in 32" [External]

Not much to see in the bug report.

  1. I attempt to switch to TTY6 from a running session
  2. system ‘freezes’
  3. I issue the R and the E of REISUB
  4. GDM reloads and I can log in
  5. the attempt at accessing TTY6 is logged
[  111.208605] sysrq: Keyboard mode set to system default
[  112.720599] sysrq: Terminate All Tasks
[  112.720843] systemd-journald[437]: Received SIGTERM.
[  112.762343] systemd[1]: systemd-timesyncd.service: Scheduled restart job, restart counter is at 1.
[  112.762687] systemd[1]: session-3.scope: Deactivated successfully.
[  112.762993] systemd[1]: systemd-udevd.service: Scheduled restart job, restart counter is at 1.
[  112.763480] systemd[1]: systemd-logind.service: Scheduled restart job, restart counter is at 1.
[  112.764498] systemd[1]: systemd-journald.service: Scheduled restart job, restart counter is at 2.
[  112.765434] systemd[1]: Stopping Network Manager...
[  112.766042] systemd[1]: Starting CUPS Scheduler...
[  112.766679] systemd[1]: Started Getty on tty6.
[  112.767182] systemd[1]: Starting Load Kernel Module drm...
[  112.768052] systemd[1]: Starting Journal Service...
[  112.768818] systemd[1]: Starting Network Time Synchronization...
[  112.769512] systemd[1]: Starting Rule-based Manager for Device Events and Files...
[  112.769955] systemd[1]: modprobe@drm.service: Deactivated successfully.
[  112.770038] systemd[1]: Finished Load Kernel Module drm.
[  112.771059] systemd[1]: Starting User Login Management...

Thanks. The incompatibility with simpledrm is a known problem and the only real workaround is setting fbdev=1. The Arch workaround that looks for nvidia_drm.modeset=1 on the kernel command line should only be necessary if you’re loading it with fbdev=0.

For #2, can you please try booting with only one monitor connected?

Unbelievable that none of us who help folks on the forums have ever ventured that troubleshooting step. Facepalm.

I was prepared to give you a matrix of combinations of monitors/parameters, but immediately tried the obvious…

My custom kernel 6.14.11 is built with CONFIG_SYSFB_SIMPLEFB=n, taking the simpledrm device and the Arch patch out of the equation.

I booted with only my primary DisplayPort monitor connected and only nvidia_drm.fbdev=1 kernel parameter.

For the first time ever I’m seeing the nVidia framebuffer… it’s very obvious looking… and TTYs are functional.

EDIT: the below worked briefly, but then I got a freeze again…

Additionally, once in my session, I plugged in the 2nd monitor. Still have access to TTYs and the framebuffer is intact.

Detaching/re-attaching the DVI monitor worked around it without needing the previous workaround of (RE)ISUB.

Thanks for testing that. I have a feeling this is tracked in internal bug 4157529. I’d be sure if plugging in two monitors that use the same resolution worked, but I understand that’s hard to test if you don’t happen to have multiple monitors on hand.

Guessing they have to be the same native resolution, not just setting?

In that case, yeah I don’t have the ability to test that unfortunately.

EDIT: Also, the 2nd monitor is oriented in portrait if that matters.

Yeah, the Linux kernel has to pick the same width and height in pixels for both of them. No big deal if you can’t test that. If I’m able to push a patch to GitHub - NVIDIA/open-gpu-kernel-modules: NVIDIA Linux open GPU kernel module source, would you be interested in testing it?

As intriguing as that is I can’t… I’m one GPU generation short of open module support here on Pascal / GP107 / 1050 Ti.