[595.84] Silent unsignaled dma_fence from nvidia-drm-rendered buffer permanently hangs amdgpu reverse-PRIME sink in drm_atomic_helper_wait_for_fences (RTX 5090 + Ryzen 9950X3D iGPU)

Summary

On a hybrid desktop (RTX 5090 as primary/render GPU, AMD Ryzen 9950X3D iGPU driving one display as a reverse PRIME sink), the desktop froze mid-session: amdgpu's non-blocking atomic commit worker blocked forever in drm_atomic_helper_wait_for_fences() on a dma_fence attached to a framebuffer rendered by the NVIDIA GPU. The fence never signaled. The NVIDIA driver logged no Xid or NVRM error at the time, and amdgpu logged no ring/reset errors either: the fence producer simply never completed, which violates the dma_fence signaling contract and permanently wedges the sink GPU's commit pipeline. Recovery required a hard power-off.

System

• Driver: 595.84 (open kernel modules), Ubuntu package nvidia-driver-595-open 595.84-0ubuntu0.24.04.1
• GPU 0 (primary, X screen): NVIDIA GeForce RTX 5090 [10de:2b85], drives 2 displays directly
• GPU 1 (PRIME sink): AMD Ryzen 9 9950X3D iGPU [1002:13c0] (amdgpu), drives 1 display (3840x1100 DP panel on card2-DP-4)
• Kernel: 7.0.0-28-generic (Ubuntu 24.04 HWE)
• Session: Xorg, GNOME, nvidia X driver primary with modesetting reverse PRIME sink
• xrandr --listproviders: NVIDIA-0 (Source Output), AMD iGPU (Sink Output, Source Offload)

What happened

Timeline from the journal (boot of 2026-08-10):

1. 10:12: boot, normal session. One early nvidia-drm error at boot time (possibly unrelated): [drm:__nv_drm_nvkms_gem_obj_init [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to get memory pages for NvKmsKapiMemory
2. ~16:22: during ordinary desktop use (Chrome active, no display hotplug, no suspend/resume, no VT switch logged), a non-blocking atomic commit on the amdgpu-driven output never completed.
3. 16:24 onward: hung task warnings every 2 minutes for the same worker, wait time growing unbounded (122s, 245s, ..., 860s+):

INFO: task kworker/u129:1:1847867 blocked for more than 122 seconds.
      Tainted: G           O        7.0.0-28-generic #28~24.04.1-Ubuntu
task:kworker/u129:1  state:D stack:0     pid:1847867 tgid:1847867 ppid:2      task_flags:0x4208060 flags:0x00080000
Workqueue: events_unbound commit_work
Call Trace:
 <TASK>
 __schedule+0x2d0/0x660
 schedule+0x27/0x90
 schedule_timeout+0x104/0x110
 dma_fence_default_wait+0x213/0x2d0
 ? __pfx_dma_fence_default_wait_cb+0x10/0x10
 dma_fence_wait_timeout+0xb6/0x180
 drm_atomic_helper_wait_for_fences+0x164/0x1f0
 commit_tail+0x3b/0x1b0
 commit_work+0x12/0x20
 process_one_work+0x1af/0x430
 worker_thread+0x1bf/0x350
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xfb/0x140
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x1f8/0x2b0
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
 </TASK>

4. The session degraded progressively (D-Bus service activations started timing out from 16:52), ending in a full UI freeze and a hard reset around 21:00.

Why I believe the unsignaled fence was produced by the NVIDIA driver

• commit_work/commit_tail is the generic DRM helper commit path. nvidia-drm does not use it (it installs its own .atomic_commit = nv_drm_atomic_commit in nvidia-drm-drv.c and manages flips via its own flip_list; there is no drm_atomic_helper_commit call in nvidia-drm). So the hung worker belongs to amdgpu, the only other KMS driver in the system.
• The only display amdgpu drives is the reverse PRIME sink output. The framebuffers it scans out are rendered by the NVIDIA GPU and shared to amdgpu, so the plane fences that drm_atomic_helper_wait_for_fences() waits on are produced on the NVIDIA side.
• amdgpu logged no errors of any kind (no ring timeout, no GPU reset, no page faults) before, during, or after the hang. It is passively waiting.
• The NVIDIA driver logged no Xid and no NVRM message at hang time, so whatever failed on the producer side failed silently.

Note that the sink side has no defense: drm_atomic_helper_wait_for_fences() waits with no timeout, so a single unsignaled fence permanently freezes that CRTC's commit pipeline, and the resulting stall gradually took down the whole session.

Frequency

Once so far (2026-08-10). Previous and subsequent boots with the same driver and workload are clean. I realize a single occurrence with no reproducer limits what you can do with this, but the fence-provenance analysis above seemed worth reporting since the failure is silent (no Xid, nothing in dmesg from either driver) and unrecoverable from userspace.

I will capture nvidia-bug-report.sh over SSH if it recurs, and can provide the full journal for the affected boot on request.

Related

Possibly adjacent to the explicit-sync/dmabuf interop rework mentioned in the R610 release notes; if this class of producer-side fence loss is known and fixed in 610, a pointer to the relevant change would be appreciated (and a backport to R595 would help Ubuntu 24.04 LTS users, since 595 is the default there for Blackwell).

Start with the reported call path through drm_atomic_helper_wait_for_fences() and the NVIDIA path in nvidia-drm-drv.c, then review the affected boot journal. If the hang recurs, capture nvidia-bug-report.sh over SSH and compare it with the amdgpu and NVIDIA logs. Done means identifying a reproducible producer-side fence failure or a concrete driver change to investigate.