nvidia-modeset: nvHandleCpEventDeferredWork displayId invalid on suspend — monitor doesn't recover after resume (HP USB-C Dock G5, Optimus laptop)

[cpedja1]

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

Fedora Linux 44 (Workstation Edition)

Kernel Release

Linux fedora 7.2.5-200.fc44.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Sep 11 15:11:05 UTC 2026 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 4060 Laptop GPU

Describe the bug

When suspending the system while docked via a USB-C dock with an external monitor connected, nvidia-modeset logs a "displayId invalid" error right before suspend. After resume, the external monitor does not come back (no signal), even though the kernel DRM connector still reports "connected". The internal laptop display works fine. The issue is reproducible on every suspend/resume cycle while docked.

To Reproduce

1. Dock the laptop to an HP USB-C Dock G5, with an external monitor connected to the dock's DisplayPort output (DisplayPort Alt Mode over USB-C).
2. Suspend the system (systemctl suspend, or close the lid / use the suspend menu option).
3. Resume the system.
4. Observe that the external monitor shows no signal, while the internal laptop screen (eDP) works normally.

Bug Incidence

Always

nvidia-bug-report.log.gz

nvidia-bug-report-clean.log.gz

More Info

Summary

On suspend (s2idle), nvidia-modeset logs a displayId invalid error for the
external monitor connected through a USB-C dock. After resume, the external
monitor stays black / no signal, even though the kernel DRM layer still
reports the connector as connected. The GPU appears to lose track of the
display's internal state during the suspend transition.

Environment

• Laptop: HP Victus by HP Gaming Laptop 16-r1xxx (Intel Core i7-14700HX + NVIDIA GeForce RTX 4060 Laptop, Optimus/hybrid graphics)
• GPU driver: NVIDIA 615.71.09 (proprietary, RPM Fusion akmod-nvidia package)
• OS: Fedora 44
• Kernel: 7.2.5-200.fc44.x86_64
• Dock: HP USB-C Dock G5 (firmware up to date: CCG5 3.1.1.1424, DMC 3.3.0.1746)
• External monitor: connected via DisplayPort Alt Mode through the dock's USB-C uplink (3440x1440 ultrawide)
• mem_sleep: reproduces on both s2idle and deep (deep additionally causes a full system hang/high fan speed requiring a hard reset — may be a separate/compounding issue on this hardware)

Steps to reproduce

1. Dock the laptop via the HP USB-C Dock G5, with an external monitor connected to the dock's DisplayPort output.
2. Suspend the system (systemctl suspend).
3. Resume the system.

Expected behavior

External monitor comes back automatically after resume.

Actual behavior

External monitor shows no signal after resume. The internal laptop screen
(eDP, Intel iGPU) works fine.

Kernel log right before suspend:

(seen with different displayId values across suspend cycles, e.g. also 0x800)

What I've tried (does NOT fix it)

• USB unbind/rebind of the dock's internal hub (Microchip USB2734)
• USB authorized/deauthorize of the whole dock's parent USB port (both USB2 and USB3 branches)
• uhubctl full power-cycle (VBUS off/on) of both the USB2 and USB3 branches of the dock
• udevadm trigger --subsystem-match=drm --action=change
• Direct DRM force-detect: echo detect > /sys/class/drm/card0-DP-2/status (status already reports connected, so this is a no-op)
• xrandr --output DP-2 --auto — the output isn't even listed in xrandr once broken
• nvidia-suspend.service / nvidia-resume.service are enabled but report Skipped due to 'exec-condition' (so they don't appear to run any recovery logic here)

What DOES fix it (workarounds)

• Physically unplugging and replugging the DisplayPort cable from the dock
• sudo systemctl restart gdm (forces Xorg to re-probe all GPU providers/outputs) — works but logs out the session
• Switching virtual terminals (Ctrl+Alt+F6 then Ctrl+Alt+F1, or sudo chvt 6 && sudo chvt 1) — works and does not log out the session; this is the most useful workaround so far

The fact that a VT switch fixes it, while every USB-level reset and DRM
sysfs detect write does not, suggests the corrupted state is specifically
inside nvidia-modeset's internal display id / event handling (matching the
nvHandleCpEventDeferredWork: displayId invalid log line), rather than
anything at the USB/PHY/link-training level.

Additional notes

• This looks similar to other long-standing reports of nvidia-modeset
  suspend/resume display corruption across many driver versions and GPUs, e.g.:
  • RTX3070 fails to resume from suspend. Fail to determine display capabilities. Failed to tear down display. #360
  • https://forums.developer.nvidia.com/t/suspend-fails-on-570-124-04-drivers/326550
  • https://forums.developer.nvidia.com/t/bug-sporadic-hang-on-suspend-gpu-failed-to-query-display-engine-channel-state/334745
• Happy to attach a full journalctl -b dump, nvidia-bug-report.sh output, or test proposed fixes.