RTX 4080 Laptop / 620.70.06: intermittent S3 resume DMA failure; request GSP NvLog interpretation

[bgd-fwc]

Please route this to NVIDIA Linux graphics/GSP engineering. I am requesting
interpretation of already captured firmware logs to identify the initiating
failure, rather than access to NVIDIA's private logging database.

Summary

On an ASUS G634JZ with NVIDIA RTX 4080 Laptop plus Intel i915, some suspend/wake
cycles leave the desktop frozen or blank. The kernel logs:

nvidia-modeset: ERROR: GPU:0: Failed to initialize DMA.

Hyprland subsequently aborts after glGetGraphicsResetStatus returns 0x8255
(GL_UNKNOWN_CONTEXT_RESET), confirmed by offline core analysis. Linux remains
active: automatic diagnostics finish, nvidia-smi responds, and USB/power-key
events continue to be logged. A forced reboot has been needed to recover.

The characteristic failure is captured with both the service-based NVIDIA
suspend path and native kernel suspend notifiers, using the same 620.70.06
firmware build. A successful overnight native-path wake is retained for
comparison. Failures are intermittent; a short sleep or a successful night
does not establish a fix.

I am posting in Q&A because I have not established that this is specific to
the open kernel modules versus the same-version proprietary modules. I cannot
honestly make the proprietary-driver comparison required by the issue form.
Please advise if this should move to a different NVIDIA support channel or
be associated with an internal bug.

System and effective configuration

• ASUS ROG Strix G634JZ, BIOS G634JZ.334; Intel Core i9-13980HX.
• Intel Raptor Lake-S UHD / i915 (8086:a788), NVIDIA RTX 4080 Laptop AD104M
  (10de:27e0).
• Arch-based Omarchy; kernel 7.2.15-1-omarchy, not an -rc kernel.
• nvidia-open-beta-dkms 1:620.70.06-1; nvidia-utils-beta 620.70.06-1.1.
• Hyprland 0.56.2-4; Aquamarine 0.15.1-1; Wayland.
• NVIDIA is the primary renderer; Intel drives internal eDP-1
  (2560x1600 at 240 Hz), NVIDIA drives external BenQ RD320U DP-5
  (3840x2160 at 60 Hz).
• Actual sleep mode: deep/S3. The owner's usual setup is AC power, lid open;
  the fault-time snapshot does not independently record AC/lid state.
• PreserveVideoMemoryAllocations=1, TemporaryFilePath=/var/tmp,
  EnableS0ixPowerManagement=0, DynamicPowerManagement=3.
• UseKernelSuspendNotifiers=1 for November 11 and 14 failures and November 10
  successful comparison. It was 0 for the November 9 failed-wake capture.
• Legacy NVIDIA systemd sleep units remain enabled in the native configuration;
  the installed nvidia-sleep.sh exits early when the native path omits
  /proc/driver/nvidia/suspend. Their presence alone does not establish duplicate
  suspend operations.
• Packaged sleep configuration leaves user sessions unfrozen
  (SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0).
• No BIOS or power settings changed between November 13 and 14, per the owner.

Reproduction

1. Boot and log into Hyprland with the internal panel and external display
   connected, NVIDIA primary rendering, AC power and the lid open.
2. Request system suspend (systemctl suspend); systemd selects deep/S3.
3. Leave suspended and wake with the keyboard. In the latest capture, sleep
   lasted approximately 11 hours 27 minutes. An earlier capture also failed
   after a short suspend, so overnight duration is not established as necessary.
4. Sometimes the desktop is frozen/unusable after wake; the DMA error appears
   and the compositor later aborts after graphics-context loss.

Expected: displays and graphics contexts recover and the session remains usable.
Observed: unusable graphics despite continuing kernel/service activity.
Incidence: sometimes; three saved failed-wake firmware dumps are compared here.

Latest incident: November 14, 2026

Times are Europe/Bucharest, EET (UTC+02:00).

Nov 13 22:22:44.701 Kernel enters deep suspend.
Nov 14 09:49:42.084 Device resume completes; graphics initialization continues.
09:49:42.367 First instance of the recurring RM metadata quartet below.
09:49:42.551 Second instance of that quartet.
09:49:54.081 nvidia-modeset: Failed to initialize DMA.
09:49:54.182 Kernel records suspend exit.
09:49:54.405 Existing fault-triggered collector starts diagnostics.
09:49:55-09:50:03 nvidia-bug-report.sh --safe-mode and nvidia-smi finish.
09:50:25 Follow-up capture finishes; all eight commands exit zero.
09:50:34.798 Owner unplugs monitor USB hub; input devices disconnect.
09:50:38.819 Hyprland aborts, followed by secondary desktop-process faults.
09:51:09/34/35 logind still receives power-key events.
09:51:22-27 USB disconnect/reconnect events continue.
09:52:20 Next boot after forced restart.

Unplugging USB changed the laptop display and it eventually went dark; it did
not restore a usable desktop. Ctrl+Alt+F3 on the laptop keyboard produced no
usable console. The first GPU error and completed capture precede the unplug.
The crash-report tail mentions restoration after a VT switch, an unavailable
multi-GPU restore buffer, and SYN_DROPPED on both keyboards and the touchpad;
it has insufficient timestamps to assign each entry to a particular action.

Live state and core findings

Hyprland was runnable in userspace in initial, +10 s and +30 s snapshots;
NVIDIA modeset workers were sleeping in their queue loops. There was no
persistent D-state task in the later snapshots. RAM available: 17.3-17.6 GiB.
nvidia-smi -q completed with Display Active Enabled, GPU Recovery Action None,
P8, and approximately 32.7 C. This does not imply rendering was healthy.
No matching Xid, kernel panic, GSP heartbeat timeout, OOM kill or NVMe I/O
failure was identified in the incident window.

The core confirms an explicit abort in Render::GL::CHyprOpenGLImpl::begin.
Disassembly identifies the saved reset status as 0x8255. This establishes
the compositor's immediate failure mechanism, not why the context was lost.
No process-memory core is included in the shared evidence.

Requested GSP firmware interpretation

All four locally preserved raw firmware logs identify GSP build:

7255cd9d48aeb639bff7e6c5d61f723ebcceb4a1

A structural parser following the matching public NvLog v13 / LibOS v2
layouts extracts the same RM task-ID-3 quartet twice in each failed wake:

0x2dcd20 -> 0x3d8950 -> 0x3d8938 -> 0x3d88d8

First-record times of the two groups:

• November 9, service path: 15:23:56.282937248 / 15:23:56.292545440.
• November 11, native path: 10:23:17.416130528 / 10:23:17.603240192.
• November 14, native path: 09:49:42.367098496 / 09:49:42.550628928.

The quartet is absent in the retained successful November 10 native wake
comparison. The November 14 first 0x3d8938 record has these nine arguments:

0x80, 0x1c8db58, 0x1c8d6f0, 0x0, 0x64600000,
0xd, 0x1c8e898, 0x9, 0x1c8e988

The second group changes several arguments. Original dumps and exact extracted
records are preserved locally for transfer to NVIDIA. These numbers are unresolved metadata offsets and raw
arguments: we do not claim they are instruction addresses, errors, or causal.
The public parser cannot recover stripped message strings or severity.
Host journal and firmware timestamps use different clocks; nanosecond-looking
precision is not evidence of corresponding cross-clock accuracy.

Please help establish:

1. What messages, severities and source locations do these RM offsets map to
   in the matching build, and what do their arguments represent?
2. Do the two repeated groups identify the channel, engine or state leading to
   __nvPushTestPushBuffer failing its post-resume test NOP? If they are normal
   records, which retained firmware records identify the initiating failure?
3. Why can this leave graphics contexts lost while GPU management still reports
   no recovery action, and why does it reproduce on both suspend paths?
4. Is this a known issue, and what supported capture would distinguish a GPU
   firmware/driver problem from platform/BIOS interaction?
5. How should the complete original fault-time nvidia-bug-report.log.gz files
   be transferred privately to NVIDIA engineering? Please request any additional
   evidence before a reset/reload destroys the relevant state.

Other observations and limitations

• spd5118 temperature-sensor resume failures (-6) also occur in the successful
  November 10 wake; they do not distinguish these failed wakes.
• The system NVMe link has previously known correctable PCIe receiver errors.
  At the latest checkpoint: 94,334 correctable, zero nonfatal and zero fatal;
  no NVMe reset/I/O failure was identified in this incident. We do not claim
  the link is certified healthy or that this proves unrelatedness.
• The temporary multi-process overnight recorder had stopped November 13 noon;
  it was not active during the latest failure. The event-triggered diagnostic
  collector and suspend checkpoints were present. Observer effects cannot be
  fully excluded; the heavy fault capture starts after the DMA error.
• A separate unexplained idle freeze lacks this same evidence and is not
  asserted to have the same cause.
• The closest searched display-wake report, issue 615.71.09: display deadlock on DPMS wake — KWin modeset holds nvkms pmlock while blocked on RM API lock in DisplayPort getLinkConfig (Flip event timeout) #1371, describes a captured
  persistent kernel-lock wait during DPMS wake. These captures show S3 wake,
  DMA initialization failure and runnable Hyprland; identity is not established.

Evidence availability

Four unchanged firmware NvLog buffers (November 9/11/14 failed wakes and the
November 10 successful-wake comparison), the complete original safe-mode vendor
reports, and focused timeline/core-analysis excerpts are preserved locally.
A comparison package with build IDs, checksums and exact record arguments is
ready. Please advise a private NVIDIA channel for transferring the originals.
No process-memory core is included in the prepared transfer package.

SHA-256 of raw firmware logs:
20261109-failed-service: 275a54dcd3a1f86067d729facb96677ec1d5a54d7e452f75acec3447b93ae0a5
20261110-success-native: 03f32ceb2bd13dbb70202a9182a196496f84bb451989cec8a14bc5a05cc18b56
20261111-failed-native: 0468745e95c8c897dbbc73d51fb612b22c2b26349a6272c4d0c057959545e0a9
20261114-failed-native: 562c25a149c4b3026287380b3127c07ebae653f96ebda4f96eb9fd8faad34827

Prepared with Codex from local diagnostic captures. No NVIDIA interpretation
of the firmware messages has yet been obtained.