Summary
On an RTX 5080 Laptop (Blackwell, GB203) with the open kernel module 610.43.02, hot-plugging a 4K@120 HDMI 2.1 display into the laptop's HDMI port (which is wired to the dGPU) makes the driver attempt HDMI FRL link training. It fails, and instead of falling back to TMDS the driver melts down: ~2 s later a GPU logs Xid 79 "GPU has fallen off the bus", followed by an unbounded flood of API_GPU_ATTACHED_SANITY_CHECK failed, and the entire system hard-crashes. 100% reproducible.
The same display + cable + port works fine at 4K@120 under Windows 11 on the same machine, so this is a Linux-driver-side issue, not hardware.
Hardware
- Laptop: Razer Blade 16 (2026), Intel Core Ultra 9 386H (Panther Lake)
- GPU: NVIDIA GeForce RTX 5080 Laptop (GB203, PCI
10de:2c59). The laptop's physical HDMI port is wired to this dGPU (DRM connector card1-HDMI-A-1); the Intel iGPU drives only the internal eDP panel.
- Sink: LG OLED 4K TV, HDMI 2.1, native 4K@120 (FRL). EDID manufacturer
GSM.
- Cable: certified Ultra High Speed HDMI (48 Gbps).
- (An RTX 5090 eGPU over Thunderbolt 5 is also present in the captured log — see the note below; it is not required to reproduce.)
Software
- NVIDIA open kernel modules 610.43.02 (build date 2026-05-28),
nvidia_drm modeset=1 fbdev=1
- Kernel: 7.1.0-rc5 (CachyOS), x86_64
- Desktop: KDE Plasma 6 / KWin (Wayland)
Steps to reproduce
- Boot to a Plasma Wayland session (internal panel on the Intel iGPU eDP).
- Hot-plug a 4K@120 HDMI 2.1 display into the laptop's native HDMI port (wired to the RTX 5080).
- The driver attempts HDMI FRL link training -> it fails -> ~2 s later a GPU falls off the bus (Xid 79) -> RM spirals -> the whole session/system hard-crashes. Reproducible every time.
Relevant dmesg
nvidia-modeset: WARNING: GPU:0: HDMI FRL link training failed.
NVRM: Xid (PCI:0000:5a:00): 79, GPU has fallen off the bus.
NVRM: nvAssertFailedNoLog: Assertion failed: !(pCurThread->flags & THREAD_STATE_FLAGS_IS_ISR_LOCKLESS) @ gpu_rmapi.c:644
NVRM: GPU 0000:5a:00.0: GPU has fallen off the bus.
NVRM: krcRcAndNotifyAllChannels_IMPL: RC all channels for critical error 79.
NVRM: _threadNodeCheckTimeout: API_GPU_ATTACHED_SANITY_CHECK failed! <-- repeats ~61x until the session dies
The trigger is nvidia-modeset: WARNING: GPU:0: HDMI FRL link training failed on GPU:0 (the RTX 5080 — the laptop HDMI port).
Note on the eGPU: in this particular captured dmesg an RTX 5090 eGPU was also connected, and it is the device that logged Xid 79 (PCI:0000:5a:00) as collateral once the RM started failing. The crash also reproduces with the eGPU physically detached (only the RTX 5080 present), so the eGPU is incidental — the root trigger is the HDMI FRL link-training failure on the 5080. (A separate dmesg for the eGPU-absent case is hard to capture because the failure takes the system down before journald flushes; happy to try to obtain one if useful.)
Expected vs actual
- Expected: if HDMI 2.1 FRL link training fails, fall back to TMDS (HDMI 2.0) or fail the modeset gracefully. A failed link-train must never take down the GPU / driver / system.
- Actual: the FRL failure cascades into Xid 79 + an RM
API_GPU_ATTACHED_SANITY_CHECK meltdown + a full system crash.
What has been ruled out
- Not the hardware/monitor/port: the identical port + cable + TV work at 4K@120 under Windows 11 on the same machine.
- Not the cable: certified Ultra High Speed (48 Gbps) HDMI cable.
- Not the eGPU: reproduces with the eGPU removed.
Workaround
Driving the same TV at 4K@120 over DisplayPort (a Thunderbolt 5 dock that converts DP->HDMI, so the GPU never attempts HDMI FRL itself) works flawlessly. There appears to be no NVIDIA module parameter to disable FRL / force TMDS (AMD exposes amdgpu.dc_feature_mask=0x400 for this), so the native HDMI port is effectively unusable above 4K@60 on Linux, and is dangerous to even hot-plug because it crashes the machine.
Possibly related
nvidia-bug-report.log.gz available on request.
Summary
On an RTX 5080 Laptop (Blackwell, GB203) with the open kernel module 610.43.02, hot-plugging a 4K@120 HDMI 2.1 display into the laptop's HDMI port (which is wired to the dGPU) makes the driver attempt HDMI FRL link training. It fails, and instead of falling back to TMDS the driver melts down: ~2 s later a GPU logs Xid 79 "GPU has fallen off the bus", followed by an unbounded flood of
API_GPU_ATTACHED_SANITY_CHECK failed, and the entire system hard-crashes. 100% reproducible.The same display + cable + port works fine at 4K@120 under Windows 11 on the same machine, so this is a Linux-driver-side issue, not hardware.
Hardware
10de:2c59). The laptop's physical HDMI port is wired to this dGPU (DRM connectorcard1-HDMI-A-1); the Intel iGPU drives only the internal eDP panel.GSM.Software
nvidia_drm modeset=1 fbdev=1Steps to reproduce
Relevant dmesg
The trigger is
nvidia-modeset: WARNING: GPU:0: HDMI FRL link training failedon GPU:0 (the RTX 5080 — the laptop HDMI port).Note on the eGPU: in this particular captured dmesg an RTX 5090 eGPU was also connected, and it is the device that logged Xid 79 (
PCI:0000:5a:00) as collateral once the RM started failing. The crash also reproduces with the eGPU physically detached (only the RTX 5080 present), so the eGPU is incidental — the root trigger is the HDMI FRL link-training failure on the 5080. (A separate dmesg for the eGPU-absent case is hard to capture because the failure takes the system down before journald flushes; happy to try to obtain one if useful.)Expected vs actual
API_GPU_ATTACHED_SANITY_CHECKmeltdown + a full system crash.What has been ruled out
Workaround
Driving the same TV at 4K@120 over DisplayPort (a Thunderbolt 5 dock that converts DP->HDMI, so the GPU never attempts HDMI FRL itself) works flawlessly. There appears to be no NVIDIA module parameter to disable FRL / force TMDS (AMD exposes
amdgpu.dc_feature_mask=0x400for this), so the native HDMI port is effectively unusable above 4K@60 on Linux, and is dangerous to even hot-plug because it crashes the machine.Possibly related
HDMI FRL link training failedsignature)nvidia-bug-report.log.gzavailable on request.