Display gets stuck in FRL mode during reboot

Graphics / Linux Linux
1

I’ve been diagnosing an issue for a few days and I believe I have narrowed it down to a driver issue causing the connected display to become stuck in FRL signal mode during reboots.

The behavior I’ve been experiencing is a black screen during the boot process that causes the bootloader menu to not be visible. I believe this is due to the BIOS/UEFI and bootloader stages of the boot process not supporting a FRL signal, only TMDS.

I do not experience this issue with the latest Windows driver or with the open source nouveau drivers. With the former correctly transitioning from an FRL signal to TMDS signal during reboots and the latter not supporting FRL at all, avoiding the issue.

I am using an HDMI 2.1 monitor connected to an RTX 3060 Ti. I run my desktop at 4k120 RGB 10b 4L8. I am able to view the connection information on an overlay on my monitor and I observe it staying in FRL mode for the duration of the reboot. On Windows, I observe the monitor correctly transitioning from FRL to TMDS and then back to FRL as expected.

Happy to provide any logs or additional information you may need to help get the ball rolling on a fix.

565 release feedback & discussion
2

I am seeing the same issue. I think this may be a consequence of fbdev=1 being essentially mandated on kernel 6.11. It started when I enabled that.

1 Like
3

I have this issue too since several weeks and now found a workaround which I like to share.
This will only work with kernel 6.11.4 or newer, otherwise you likely will get a black screen after login:

  1. Disable boot splash to get a terminal output on reboot, e.g. if using grub, remove splash from GRUB_CMDLINE_LINUX_DEFAULT and then update the boot config.
  2. Set fbdev kernel parameter to 0. This will disable the gpu framebuffer in the tty. Depending on your distro, either look for an nvidia config under /etc/modprobe.d or at /usr/lib/modprobe.d. The line should now contain: options nvidia_drm modeset=1 fbdev=0
  3. regenerate initramfs: mkinitcpio -P
  4. The next reboot will still have no bios screens but after the second one you should now always see the bios messages and boot-loader. You will also notice, that the boot messages on startup and shutdown/reboot in the tty now have a much lower resolution than before.

I have tested this with cachyos as a reference. Furthermore, I guess this only affects HDMI 2.1 connections. If I use a monitor, which does not support HDMI 2.1 or connect via Display port, then the reboot screen is visible without any modification. This is also the case if I disable HDMI ultra deep color on my LG C2 (however this is no real solution since you loose HDR, 120 HZ, etc.)

System is a RTX 4090 and LG OLED42C2

1 Like
4

This is my finding as well. I also have an LG C2.

5

@jack.bauer or @UrbenLegend , any link or follow up from this? Is there a bug report we can follow?

I’m still encountering this display on re-boot issue on NixOS 24.11 with a RTX 4090 connected to an LG C3 TV:

$ uname -a
Linux dox 6.6.90 #1-NixOS SMP PREEMPT_DYNAMIC Fri May  9 07:44:08 UTC 2025 x86_64 GNU/Linux
$ nvidia-smi 
Sat May 17 21:29:23 2025       
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 565.77                 Driver Version: 565.77         CUDA Version: 12.7     |
|-----------------------------------------+------------------------+----------------------+

Also tested a newer Linux kernel and Nvidia driver, but to no avail:

> uname -a
Linux dox 6.12.28 #1-NixOS SMP PREEMPT_DYNAMIC Fri May  9 07:50:53 UTC 2025 x86_64 GNU/Linux
> nvidia-smi 
Sat May 17 22:00:25 2025       
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 570.144                Driver Version: 570.144        CUDA Version: 12.8     |
|-----------------------------------------+------------------------+----------------------+

Note this is using the default kernel params as declared here:

FYI, the snippet from my nix config:

  boot.kernelPackages = pkgs.unstable.linuxPackages;
  hardware.nvidia-container-toolkit.enable = true;
  hardware.nvidia = {
    open = true;
    package = pkgs.unstable.linuxPackages.nvidia_x11;
    prime.intelBusId = lib.mkDefault "PCI:0:2:0";
    prime.nvidiaBusId = lib.mkDefault "PCI:1:0:0";
    prime.sync.enable = lib.mkForce true;
    prime.offload = {
      enable = lib.mkForce false;
      enableOffloadCmd = lib.mkForce false;
    };
  };
6

Nvidia has said they are tracking the issue: GPU is not properly transitioning HDMI 2.1 displays from FRL (Fixed Rate Link) to TMDS (Transition Minimized Differential Signaling) during reboots · Issue #721 · NVIDIA/open-gpu-kernel-modules · GitHub

1 Like
7

Thanks @UrbenLegend ! In the meantime, I’ve opted to simply add a kernel param to reboot the PCI device:

  boot.kernelParams = [ "reboot=pci" ];

While not as fast as a warm reset (for my motherboard & RAM), it at least resets both GPU and HDMI ports.

1 Like
8

can you guys give this kernel parameter a try? I would like to know your results. Confirm on the monitor / LG that you actually are running at 8bit afterwards, not 10bit.

nvidia-modeset.hdmi_deepcolor=0

1 Like
9

@adolfotregosa , I swapped my use of the reboot=pci kernal parameter for your suggestion of nvidia-modeset.hdmi_deepcolor=0, and then rebooted the Linux install two time to allow for the effect to propagate through the entire boot cycle.

Delightfully, it does seem to resolve the aforementioned boot menu display issue, without the need to cold reset, i.e. resorting to PCI “reboot”. When inspecting the VRR Information via the LG TV’s info diologe popup:

https://www.lg.com/ca_en/support/product-support/troubleshoot/help-library/cs-CT52001643-20153165982189/?srsltid=AfmBOorlSVrIf_UEo-vNl-zokf6w7akd7eTdn8wV9KUWwp4pXDTErz1N

The results over the course of the second boot up cycle are:

nvidia-modeset.hdmi_deepcolor=0

BIOS UEFI Menu

VRR Information
---
- 60Hz
- FIXED
- 3840 x 2160P@60
- RGB 8b TM SDR

Kernel startup TTY

VRR Information
---
- 59.39Hz
- VRR
- 3840 x 2160P@60
- RGB 8b TM SDR

SDDM Login Menu

VRR Information
---
- 118.68Hz
- VRR
- 3840 x 2160P@120
- RGB 8b 4L8 SDR

User login TTY

VRR Information
---
- 59.39Hz
- VRR
- 3840 x 2160P@60
- RGB 8b TM SDR

KDE Plasma desktop

VRR Information
---
- 118.68Hz
- VRR
- 3840 x 2160P@120
- RGB 8b 4L8 HDR10

Kernel shutdown TTY

VRR Information
---
- 59.39Hz
- VRR
- 3840 x 2160P@60
- RGB 8b TM HDR10

reboot=pci

BIOS UEFI Menu

VRR Information
---
- 60Hz
- FIXED
- 3840 x 2160P@60
- RGB 8b TM SDR

Kernel startup TTY

VRR Information
---
- 59.39Hz
- VRR
- 3840 x 2160P@60
- RGB 10b 4L6 SDR

SDDM Login Menu

VRR Information
---
- 118.68Hz
- VRR
- 3840 x 2160P@120
- RGB 10b 4L10 SDR

User login TTY

VRR Information
---
- 59.39Hz
- VRR
- 3840 x 2160P@60
- RGB 10b 4L6 SDR

KDE Plasma desktop

VRR Information
---
- 118.68Hz
- VRR
- 3840 x 2160P@120
- RGB 10b 4L10 HDR10

Kernel shutdown TTY

VRR Information
---
- 59.39Hz
- VRR
- 3840 x 2160P@60
- RGB 10b 4L6 SDR

Might I ask @adolfotregosa, why disabling the nvidia modset for hdmi_deepcolor properly transitions 4L8 to TM ? I’d still appreciate being able to take full advantage of 10bit.

FYI, addtional info about the test system:

Operating System: NixOS 24.11
KDE Plasma Version: 6.2.5
KDE Frameworks Version: 6.8.0
Qt Version: 6.8.3
Kernel Version: 6.12.28 (64-bit)
Graphics Platform: Wayland
Processors: 32 × Intel® Core™ i9-14900K
Memory: 188.4 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 4090/PCIe/SSE2
Manufacturer: ASUS
10

It was a hunch because it also happened to me when nvidia made 10bit standard. If you don’t need 10bit color, until this is fixed, it’s a workaround. We have no other choice. Either we wait until the driver loads or we are stuck with 8bit color.

1 Like
11

This has finally been resolved in 580.105.08

1 Like
12

Can confirm that `580.105.08` resolved this issue on my local setup. Exact sha followed from here: