RTX 5070 / Samsung G95NC: blank or static after DPMS wake on 610.57.04

Graphics / Linux Linux
, , , ,
1

My Samsung Odyssey Neo G9 G95NC intermittently wakes blank or displaying static after monitor DPMS sleep. The PC itself remains awake. A refresh-rate change restores the picture. This reproduces with HDMI disconnected and PBP disabled, with both the original and a replacement DisplayPort cable.

Environment

  • GPU: NVIDIA GeForce RTX 5070
  • NVIDIA driver and open kernel modules: 610.57.04
  • Kernel: 7.2.5-3-omarchy
  • Distribution: Omarchy / Arch Linux
  • Hyprland: 0.56.2-2
  • Aquamarine: local 0.15.0-2.1, based on 0.15.0-2 with upstream callback-lifetime fix 61ddacaf586edb35604e7db4ccf6926a2c516cf1. This addressed a separate compositor crash but did not prevent the visual wake failure.
  • Samsung firmware: M-C9557GGPA-1009.2
  • Samsung test mode: 3840 x 2160 at 119.88 Hz
  • Second display: Philips PHL 242G5, 1920 x 1080 at approximately 144 Hz
  • VRR disabled during test baselines.

Reproduction

  1. Boot with Samsung DisplayPort connected, HDMI disconnected and PBP off. Verify a normal picture.
  2. Disable displays, wait 30 or 90 seconds, then enable them. Installed Hyprland commands:
hyprctl dispatch 'hl.dsp.dpms({ action = "disable" })'
hyprctl dispatch 'hl.dsp.dpms({ action = "enable" })'
  1. Samsung can return blank or with static. The failure is intermittent, not every cycle. Software can report an active output, DPMS on and the original resolution/refresh despite the visible failure.
  2. Changing Samsung to 59.94 Hz and back to 119.88 Hz restores the normal picture. Only Samsung is changed; Philips is unaffected by recovery. Reboot also restores the Samsung.

Controlled comparisons

  • DisplayPort 2.1: blank/static reproduced with PBP off and HDMI disconnected. Wake also failed from a stable 59.94 Hz baseline, so leaving the refresh low did not prevent it.
  • DisplayPort 1.4: selected in the monitor menu, then rebooted to a visually normal baseline. One 30-second cycle woke blank, despite successful off/wake responses and no compositor restart.
  • Replacement DisplayPort cable, same sockets, DisplayPort 1.4: first cycle passed. Three further logged reliability cycles produced normal picture after two 30-second intervals, then static after a 90-second interval. Refresh-toggle recovery restored the picture. Cable replacement has not eliminated the fault. Duration is not isolated from repeated-cycle history.
  • A temporary direct-DRM Weston session also failed to wake normally, but selected 3840 x 1080 at 60 Hz rather than the requested 4K mode. Both screens failed there, so this is not an exact matched comparison or proof of the same underlying cause.

Driver evidence
A DisplayPort 2.1 cycle with temporary DRM and NVIDIA modeset debug logging captured:

POWER_UP_PHY failed for device 0.8 (reason: 256)
POWER_UP_PHY timeout
Poll ChannelEQ Interlane Align failed.

AUX communication, DSC-state query and payload/ACT failures followed, then device loss and re-detection. The user-visible symptom in this traced cycle was blank. An active CRTC/framebuffer and delivered DRM events did not certify a normal picture.

Read-only inspection of matching source identifies reason 256 as internal NakTimeout, with a four-second message reply timeout. ensureMstNodesPoweredUp logs failure but returns void, allowing attach to continue into training. The alignment polling error does not uniquely distinguish a timeout from an RM/control failure. The initiating driver-versus-monitor/link cause remains unproven.

Importantly, the later DisplayPort 1.4 blank/static failures did NOT contain that PHY/alignment/AUX/DSC/ACT error sequence in their captured event logs. Those errors are therefore not necessary for the visual symptom.

All temporary debug parameters were restored after each capture. No permanent driver parameters or monitor configuration changes were made during these tests.

Attachments
I have a standard NVIDIA diagnostic report captured during visible static before recovery, plus an evidence archive containing the driver trace, before/after state, per-cycle visual results and source references. The standard diagnostic report is from an earlier failure, not the final replacement-cable reliability cycle.

Request
Could NVIDIA investigate this wake-restoration failure, provide a tracking bug ID, and advise which additional diagnostics would distinguish failed sink/link restoration from GPU stream state? In particular, is continuing after the PHY power-up timeout expected, and how can the raw alignment-poll return status and error bits be captured safely?

nvidia-bug-report.log.gz (272.1 KB)

nvidia-wake-evidence.tar.gz (756.6 KB)