Nvidia-drm: Stub EDID cached on wake for slow-waking DisplayPort monitor — semsurf error and pageflip timeout on head 1 (RTX 5080, 590.48.01)

Environment

  • GPU: NVIDIA GeForce RTX 5080

  • Driver: nvidia-open-dkms 590.48.01-6 (nvidia-drm.modeset=1)

  • Kernel: 6.18.9-arch1-2 (Arch Linux)

  • Desktop: KDE Plasma 6 (Wayland / KWin)

  • Affected monitor: Samsung Odyssey G65B (DisplayPort, DP-3)

  • Second monitor: Dell P2425H (DisplayPort, DP-2, unaffected)


Summary

After suspend/resume, the Samsung Odyssey G65B intermittently comes back with only 640×480 available. The connector remains detected but the EDID returned for it is a minimal synthesised stub rather than the real monitor data. Power-cycling the monitor immediately restores the correct EDID and full mode list. No reboot or cable reconnection required.

Further investigation via nvidia-bug-report.sh revealed a second symptom on the same wake event: a semaphore surface error fires in nvidia-drm immediately on resume, followed by continuous pageflip timeouts on head 1 for ~40 seconds. KWin explicitly attributes these to the nvidia-drm driver. The EDID stub and the flip timeout appear to be two manifestations of the same broken state on head 1 post-wake.

The semsurf + pageflip timeout pattern is also reported by others on 590.48.01: on an RTX 5070 Ti in open-gpu-kernel-modules #1010 and on an RTX 5090 in this forum thread, suggesting this is a driver-level regression in 590.48.01 affecting multiple Blackwell GPUs rather than a hardware-specific issue.


EDID comparison

In the working state, /sys/class/drm/card2-DP-3/edid decodes correctly:

Manufacturer: SAM
Product: Odyssey G65B
Serial: H1AK500000
DTD 1: 2560x1440 @ ~120 Hz (native)
DTD 2: 2560x1440 @ ~60 Hz
DTD 3: 1920x1080 @ 120 Hz
HDR Static Metadata: SMPTE ST2084, max luminance 603 cd/m²

In the failed state, the same connector returns:

Manufacturer: 0x3aC4 (unrecognised)
Product: 0x0000
Serial: (none)
Week/year: 0 / 1990
All detailed timing descriptor slots: empty
No extension blocks
Checksum: 0x92

The stub has a valid checksum, so this is not a garbled read. it appears to be a driver-synthesised or zeroed internal buffer being served instead of the real EDID. The connector UUID reported by kscreen-doctor changes between states (since UUID is derived from EDID content), confirming a different blob was ingested.


Journal output — EDID read failure

org_kde_powerdevil: Retrying i2c_check_edid_exists_by_dh() tryctr=1, dh=Display_Handle[i2c-20]
org_kde_powerdevil: /dev/i2c-20, Checking EDID failed after 2 tries
org_kde_powerdevil: Unable to read EDID for /dev/i2c-20
org_kde_powerdevil: Failed to find connector name for /dev/i2c-20

kwin_wayland: EDID colorimetry xy(0.330078, 0.297852) xy(0.597656, 0.149414)
              xy(0.0605469, 0.314453) xy(0.328125, 0.00292969) is invalid


nvidia-bug-report.log — semsurf error and pageflip timeout sequence

09:43:54  nvidia-suspend.service started
09:43:55  nvidia-suspend.service completed

09:44:14  kernel: [drm:__nv_drm_semsurf_wait_fence_work_cb [nvidia_drm]] *ERROR*
          [nvidia-drm] [GPU ID 0x00000100] Failed to register auto-value-update
          on pre-wait value for sync FD semaphore surface

09:44:15  nvidia-resume.service started
09:44:15  kwin_wayland: Pageflip timed out! This is a bug in the nvidia-drm kernel driver
          [...repeats every second for ~40 seconds...]

09:45:23  kernel: [drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR*
          [nvidia-drm] [GPU ID 0x00000100] Flip event timeout on head 1
09:45:26  kernel: [drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR*
          [nvidia-drm] [GPU ID 0x00000100] Flip event timeout on head 1

The semsurf error fires before nvidia-resume even completes, then head 1 (DP-3, the Samsung) deadlocks. The same semsurf error appears on two other resume events in the log, indicating it is consistently triggered by wake. The Dell on DP-2 (head 0) is unaffected throughout.


Hypothesis

The Samsung Odyssey G65B has a characteristically slow wake: it asserts HPD before its DDC/I²C bus is ready to serve the EDID. The driver fires the DDC read immediately on HPD assertion, the monitor isn’t ready, and the stub is cached without retry. The Dell wakes faster and is never affected.

The semsurf error and pageflip cascade suggest the display pipeline for head 1 enters a broken state during resume before the connector is fully re-initialised, with the stub EDID as a downstream consequence. The fact that the same semsurf error appears across multiple Blackwell GPUs and driver versions suggests a regression in the 590 resume path rather than anything monitor-specific.


Reproduction pattern

  1. Both monitors connected via DisplayPort, system running normally

  2. Suspend system or allow monitors to sleep

  3. Resume. intermittently, DP-3 comes back with only 640×480

  4. Power-cycle the Samsung. full mode list returns immediately

  5. More likely to occur after longer sleep periods


Related reports

A full nvidia-bug-report.log is attached to my comment on issue #946.

I have the same problem for ~4 months.
I have dual monitor setup with 2 monitors connected via active optical cables. Both cables and monitors are slow to wake up. The issue does not arise when cold booting, but sometimes arises when the monitors go to sleep (system itself does not sleep).

This morning:

  • After routine DPMS blanking (screens off on idle, system stayed running), DP-2 stopped outputting signal

  • Swapping cables between GPU ports confirmed the problem followed the physical GPU port, not the cable or monitor

  • DP-2 produced no signal with either active optical or passive DP cables

  • Warm reboots did not recover the port — it remained “disconnected” in sysfs across reboots

  • Full power cycle (PSU off, cables disconnected, 60 seconds wait) recovered the port

    System info:

  • GPU: NVIDIA GeForce RTX 5080 (Gigabyte, VBIOS 98.03.6c.00.77)

  • Driver: nvidia-open 595.58.03 (nvidia-open-lts 1:595.58.03-2)

  • Kernel: 6.18.20-1-lts (Arch Linux)

  • Desktop: KDE Plasma 6.6.3, KWin Wayland

  • Monitors:

    • DP-1: LG HDR 4K (GSM, 2019) — 10m active DP optical cable
    • DP-2: MSI MS321UP (MSI, 2021) — 10m active DP optical cable
  • Cable setup: Both monitors connected via 10m active DisplayPort optical cables routed through walls