3440x1440@240 pruned after sink power-cycle, identical EDID, Windows unaffected

NVIDIA Open GPU Kernel Modules Version

615.71.09

Please confirm this issue does not happen with the proprietary driver (of the same version). This issue tracker is only for bugs specific to the open kernel driver.

• I confirm that this does not happen with the proprietary driver package.

Operating System and Version

Description: Arch Linux

Kernel Release

Linux arch-pc 7.2.6-1-bore-flto-pgo #1 SMP PREEMPT_DYNAMIC Wed, 16 Sep 2026 14:38:16 +0000 x86_64 GNU/Linux

Please confirm you are running a stable release kernel (e.g. not a -rc). We do not accept bug reports for unreleased kernels.

• I am running on a stable kernel release.

Hardware: GPU

GPU 0: NVIDIA GeForce RTX 5080 (UUID: GPU-3fdd3802-80d5-ae4a-82ba-f9faed082c27)

Describe the bug

After a physical monitor power-cycle (off ~30s, on) with the session staying on the active VT, the driver drops 3440x1440@239.99 (1485.8 MHz) from the HDMI connector's kernel mode list (42 → 41 modes) and falls back to 3440x1440@99.98 (582.75 MHz). No Xid, no watchdog, GPU stays healthy. The three EDID snapshots (healthy / degraded / restored) are byte-identical and advertise FRL 4x12G + DSC 1.2a, so this is not an EDID fetch failure. The 582 MHz fallback fits the 600 MHz TMDS ceiling while the 1485 MHz mode needs FRL+DSC, which points at FRL/link reassessment after hotplug. Toggling the monitor's FreeSync setting restores all 42 modes with EDID unchanged. Windows 11 on the same GPU, cable, port, monitor, and 240 Hz mode retains 240 across the same power-cycle. Possibly related to #1204 (same family, identical-EDID high-mode pruning), but different GPU/monitor/recovery, so filing separately.

To Reproduce

• Connect Gigabyte MO34WQC2 over HDMI, set 3440x1440@240 (mode present, 42 kernel modes, EDID advertises FRL 4x12G + DSC 1.2a)
• Keep the session on the active VT (no VT switch)
• Power the monitor off, wait ~30s, power it back on
• Observe: active mode is now 3440x1440@100, modetest -M nvidia-drm -c lists 41 modes with 3440x1440@239.99 gone; EDID bytes unchanged; link-status Good; no Xid in dmesg
• Recovery: toggling the monitor FreeSync setting restores 42 modes and 240 Hz with identical EDID

Bug Incidence

Always

nvidia-bug-report.log.gz

nvidia-bug-report.log.gz

More Info

Expected: 240 Hz mode survives a monitor power-cycle the way it does on Windows 11 on the same hardware, or at least re-validates on the next hotplug like the FreeSync-toggle path does.
Extra evidence I hold and can post on request: matched healthy/degraded/restored modetest outputs, EDID binaries with identical sha256 (8cc2a56d…) across all three states, compositor monitor states, and the journal window. Software-only recoveries attempted from degraded, all negative: compositor reload, compositor HDR toggle, DPMS off/on (once left the output black until a physical power-cycle. DPMS cycling seems unreliable here, not just ineffective), monitor disable/enable, and echo detect kernel reprobe. Proprietary-driver comparison not tested; Windows 11 comparison stated above is the cross-driver data point.

Start by reproducing the power-cycle sequence and collecting the mentioned modetest -M nvidia-drm -c output, EDID hashes, and kernel logs before and after hotplug. Trace the DRM hotplug and FRL/link reassessment path implicated by the report, using the FreeSync-toggle recovery as a comparison. Done means the 3440x1440@239.99 mode remains available or is revalidated after the monitor power-cycle without an EDID change.