RTX 5070 Laptop GPU: silent hang on s2idle resume after lid close/open (no Xid, no kernel/NVRM error)

Bug: RTX 5070 Laptop GPU — silent hang on s2idle resume after lid close/open (no Xid, no kernel/NVRM error, ~1-in-3 failure rate)

GPU / driver

• GPU: NVIDIA GeForce RTX 5070 Laptop GPU (Blackwell), hybrid with AMD iGPU (amdgpu 0000:c6:00.0) — internal eDP panel is wired to the NVIDIA GPU, not the iGPU
• Driver: nvidia-open-dkms 610.57.04 (open kernel modules)
• Tested kernels: 7.1.8-arch1-3 (mainline Arch) and 6.18.45-1-lts (Arch LTS) — identical failure on both
• Laptop: Razer Blade 16 (RZ09-0528), latest vendor BIOS/EC applied
• Distro: Omarchy 4.0.0-1 (Arch-based), Hyprland 0.56.2 (Wayland compositor)
• Sleep state: s2idle only — no S3 deep sleep available on this platform (ACPI FADT declares only S0 S4 S5)

Symptom
Closing the lid suspends cleanly (PM: suspend entry (s2idle), hyprland-suspend/nvidia-suspend units complete). Reopening the lid, the kernel resume completes cleanly and fast (typically under 2s, e.g. PM: resume of devices complete after 1889.553 msecs) with zero NVRM/Xid/DRM error output — but the internal display never comes back and the system is fully unresponsive (no SSH, no compositor IPC in the worst cases, fans sometimes spin up loud with the lid-indicator LED pulsing green as if repeatedly retrying a wake handshake). Only a hard power-cycle recovers. This reproduces roughly 1 out of every 2-3 lid cycles, sometimes on the very first cycle of a boot.

What we've ruled out (extensive per-machine investigation, ~30 test sessions):

• Not a compositor/Hyprland bug: hyprctl monitors (when reachable) reports the panel healthy (disabled: false, dpmsStatus: 1, correct mode) even during a failed cycle — the failure is invisible to the compositor's own state.
• Not amdgpu: the recurring amdgpu: Cannot find any crtc or sizes resume line is benign and unrelated — the panel is NVIDIA-driven, confirmed via card1/driver nvidia.
• Not GPU-mode/MUX config: reproduces identically under BIOS "Dedicated" and "Hybrid" (via supergfxd) modes.
• Not the charger: reproduces identically on the stock barrel charger and USB-C PD.
• Not a kernel 7.0+ regression (ruled out NVIDIA/open-gpu-kernel-modules#1117-style theory): reproduces identically on linux-lts 6.18.45, which predates that regression window.
• Not a coredump/panic: coredumpctl and /sys/fs/pstore are consistently clean; this is a true hang, not a crash. Forcing panic_on_warn=1 + drm.debug=0x1e + efi_pstore.pstore_disable=0 for several sessions never caught anything — the hang doesn't even trip a WARN.
• Not fixed by: NVreg_PreserveVideoMemoryAllocations=1, NVreg_EnableS0ixPowerManagement=1 or =0, NVreg_DynamicPowerManagement=0x00 (GC6 disable), NVreg_EnableGpuFirmware=0 (confirmed inert — GSP is mandatory on Turing+ with the open kernel modules, this option has no effect on this GPU generation), pcie_aspm=off, acpi_mask_gpe=0x0A (a genuine, confirmed-live ACPI GPE0A storm exists on this machine at ~52-54 events/min, unrelated to lid cycling — masking it did not fix the hang either), freezing the compositor around suspend/resume via SIGSTOP/SIGCONT, or forcing DPMS re-enable + monitor reconfiguration immediately after resume.
• Vendor BIOS/EC already updated to the latest available version; no change.

Leading theory
This looks like the same class of bug described in #1117 (RTX 5070 Laptop GPU, s2idle resume hang, though that report's specific kernel-version angle didn't reproduce here) and #1209 (rm_power_source_change_event GPU bus removal during s2idle), and matches the mechanism described in this NVIDIA developer forum thread on a GSP-RM firmware bug: heartbeat stops after GC6 exit, leading to fatal GPU loss (Xid 79) and broken display recovery — https://forums.developer.nvidia.com/t/gsp-rm-firmware-bug-heartbeat-stops-after-gc6-exit-leads-to-fatal-gpu-loss-xid-79-and-broken-display-recovery/366591 — except in our case no Xid is ever logged at all, suggesting whatever hangs does so before the driver even gets far enough to report the GPU as lost.

Ask
Any guidance on what to capture next would help — every angle observable from the OS side (kernel log, DRM debug, pstore, GSP firmware logs) has come back clean on a confirmed-failed cycle. Happy to provide more logs/config on request.

Start by reproducing the lid-close/open s2idle cycle and reviewing the nvidia-suspend units, kernel log, DRM debug output, pstore, and GSP firmware logs named in the report. Compare the behavior with issues #1117 and #1209 and the linked developer forum report; done should be an actionable diagnosis or a clearly identified driver or firmware component to investigate.