Hi all,
Adding supporting evidence and one new observation to the "2D OpenGL Hangs"
report at https://gitlab.freedesktop.org/drm/amd/-/issues/4663, tracked
against
58a261bfc967 ("drm/amd/display: use a more lax vblank enable policy for
older
ASICs")
I have seen the same kernel log signature on three different kernel
versions,
triggered by two different GL clients, and I believe the existing 5 s
off-delay
workaround does not cover this card because of its DCN stepping.
ENVIRONMENT
GPU AMD Radeon RX 6700 XT (Navi 22), PCI 1002:73df rev c5, DCN 3.0
VRAM 12272 MiB
VBIOS 115-D512BS0-100
Display DisplayPort, 1920x1080 @ 239.99 Hz
OS elementary OS 8 / Pantheon / Gala, X11
Mesa 25.2.8-0ubuntu0.24.04.4 (radeonsi, navi22, LLVM 20.1.2, DRM
3.64)
Xorg 2:21.1.12-1ubuntu1.8 (AMDGPU, GLAMOR acceleration)
iGPU disabled in BIOS - the dGPU is the only display device and
enumerates as card1
Kernels 7.0.0-31, 7.0.0-34, 7.0.0-38 - all affected
Recovery amdgpu gpu_recovery=1, auto-selected reset method ("bus")
Clients Xorg itself, and openboard (on-screen keyboard, Flatpak
ch.openboard.OpenBoard, Chromium/CEF)
FAULT SIGNATURE (verbatim, captured from the running system)
amdgpu 0000:03:00.0: [gfxhub] page fault (src_id:0 ring:24 vmid:7 pasid:6)
amdgpu 0000:03:00.0: Process Xorg pid 1582 thread Xorg:cs0 pid 1652
amdgpu 0000:03:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x00601030
amdgpu 0000:03:00.0: Faulty UTCL2 client ID: TCP (0x8)
amdgpu 0000:03:00.0: MORE_FAULTS: 0x0
amdgpu 0000:03:00.0: WALKER_ERROR: 0x0
amdgpu 0000:03:00.0: PERMISSION_FAULTS: 0x3
amdgpu 0000:03:00.0: MAPPING_ERROR: 0x0
amdgpu 0000:03:00.0: RW: 0x0
(repeats 4-9x depending on occurrence)
amdgpu 0000:03:00.0: ring gfx_0.0.0 timeout, signaled seq=37345, emitted
seq=37348
amdgpu 0000:03:00.0: Process Xorg pid 1582 thread Xorg:cs0 pid 1652
amdgpu 0000:03:00.0: Starting gfx_0.0.0 ring reset
amdgpu 0000:03:00.0: Ring gfx_0.0.0 reset succeeded
amdgpu 0000:03:00.0: [drm] device wedged, but recovered through reset
Second occurrence, with openboard as the faulting client:
amdgpu 0000:03:00.0: [gfxhub] page fault (src_id:0 ring:24 vmid:5
pasid:70)
amdgpu 0000:03:00.0: Process openboard pid 10092 thread openboard:cs0
pid 10114
amdgpu 0000:03:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x00501031
amdgpu 0000:03:00.0: PERMISSION_FAULTS: 0x3
amdgpu 0000:03:00.0: ring gfx_0.0.0 timeout, signaled seq=955229, emitted
seq=955232
OBSERVATIONS
1. The ring reset always succeeds and the device is reported as recovered,
yet the desktop stays frozen, because the X server's own GL context
(Xorg:cs0) is dead. The GPU is healthy; userspace is not. Recovery
requires restarting the display manager.
2. seq delta is consistently 2-3 (37345->37348, 955229->955232,
11515049->11515052) - the ring stalls almost immediately rather than
starving gradually.
3. Independent of kernel version. Observed on 7.0.0-31, 7.0.0-34 and
7.0.0-38. Rolling back to 7.0.0-34 fixed a separate display glitch
(flickering lines) but did not stop these ring timeouts.
4. Two distinct GL clients trigger it - the X server itself and openboard
-
so it does not appear tied to one application's usage pattern.
5. Early in the session. One occurrence had seq=37345, only about 37k
packets
into the session, roughly 1-2 minutes after login. Not a sustained-load
problem.
HIGH REFRESH RATE MAY AMPLIFY EXPOSURE
The vblank off-delay for DCE_HWIP < 3.5.0 is computed from the current
timing:
offdelay = DIV64_U64_ROUND_UP((u64)20 * timing->v_total *
timing->h_total,
timing->pix_clk_100hz);
config.offdelay_ms = offdelay ?: 30;
It is a small multiple of a frame, so at 240 Hz
drm_vblank_disable_and_save
fires far more often than at 60 Hz, widening the race window introduced by
58a261bfc967.
The workaround in "drm/amd/display: Restore 5s vbl offdelay for NV3x+
DGPUs"
(Leo Li, April 2026) is guarded by:
if (amdgpu_ip_version(adev, DCE_HWIP, 0) >= IP_VERSION(3, 2, 0) &&
!(adev->flags & AMD_IS_APU)) {
config.offdelay_ms = 5000;
This card is DCN 3.0, so it is excluded from that workaround and still
uses
the short computed off-delay.
The global drm.vblank_offdelay module parameter is present and reads 5000,
but the driver bypasses it for DCE_HWIP < 3.5.0, so it has no effect here.
FREQUENCY
Roughly one occurrence every few days initially, rising to several per
hour
on some days. Per-boot counts during the investigation: 1, 1, 1, 1, 1, and
one boot with 5.
REPRODUCTION
Ordinary desktop use, no games, no compute workloads. Triggers within
minutes of login in at least one case. Reproduced on three kernel
versions.
QUESTIONS
1. Is the UTCL2 TCP (0x8) / PERMISSION_FAULTS: 0x3 permission fault the
cause of the ring stall, or a symptom of it? It consistently precedes
the
timeout by about 2 seconds.
2. Would extending the 5 s off-delay workaround to DCE_HWIP >= 3.0 rather
than >= 3.2 be safe for Navi 22-class dGPUs? It would trade some power
savings for stability.
3. Should the "Restore 5s vbl offdelay" fix, currently only on the mailing
list, be considered for stable, given that no affected hardware seems
to
be excluded by the 3.2.0 guard?
NOTE ON DATA
The journal has since rotated, so the raw logs for the individual
occurrences
are no longer on disk. The excerpts above were captured directly from the
running system during the investigation. I can provide the complete kernel
log for a separate gfx_0.1.0 occurrence on the same machine if useful.
Thanks,
Wayne
