I can add a data point and some source-level analysis that might help
narrow this down.
System: Ubuntu 26.04 (resolute), kernel 7.0.0-29-generic, GPU: Radeon RX
7900 GRE (Navi 31, PCI ID 1002:744c), reproduced consistently with heavy
JS/compositing web pages (github.com specifically - repo file lists, PR
diffs). Not GNOME/Wayland-specific in my case - reproduced on XFCE/X11
too.
Captured dmesg during a freeze (fans audibly ramping for ~10s, page
unresponsive to clicks but scroll still worked):
amdgpu 0000:03:00.0: [drm] REG_WAIT timeout 1us * 100 tries -
dcn32_program_compbuf_size line:147
workqueue: dm_handle_vmin_vmax_update [amdgpu] hogged CPU for >10000us 4 times,
consider switching to WQ_UNBOUND
workqueue: dm_handle_vmin_vmax_update [amdgpu] hogged CPU for >10000us 5 times,
consider switching to WQ_UNBOUND
workqueue: dm_handle_vmin_vmax_update [amdgpu] hogged CPU for >10000us 7 times,
consider switching to WQ_UNBOUND
workqueue: dm_handle_vmin_vmax_update [amdgpu] hogged CPU for >10000us 11
times, consider switching to WQ_UNBOUND
workqueue: dm_handle_vmin_vmax_update [amdgpu] hogged CPU for >10000us 19
times, consider switching to WQ_UNBOUND
workqueue: dm_handle_vmin_vmax_update [amdgpu] hogged CPU for >10000us 35
times, consider switching to WQ_UNBOUND
workqueue: dm_handle_vmin_vmax_update [amdgpu] hogged CPU for >10000us 67
times, consider switching to WQ_UNBOUND
This eventually cascades into the browser's GPU process losing its context and
restarting (gbm_bo_import returning nullptr → CreateSharedImage: could not
create backing → viz::ExitCode: Context was lost), which is the
userspace-visible symptom.
Source analysis (linux-stable v7.1.6, so this is still present in a
build newer than what shipped this bug): the exact REG_WAIT is in
drivers/gpu/drm/amd/display/dc/hubbub/dcn32/dcn32_hubbub.c:147, in
dcn32_program_compbuf_size() — the 1us, 100 parameters match the logged
message exactly. It's reached via dm_handle_vmin_vmax_update()
(amdgpu_dm.c:533, a work_struct queued via schedule_dc_vmin_vmax()) →
dc_stream_adjust_vmin_vmax() (dc.c:1274) → hwss.set_drr(). The timeout
is not propagated as an error — the function just proceeds to
REG_UPDATE(DCHUBBUB_COMPBUF_CTRL, ...) regardless, so on timeout the
compbuf size may get committed before the DET size actually converged in
hardware.
One thing worth checking: dc_stream_adjust_vmin_vmax() is called from at
least three places with two different, non-overlapping locks:
the workqueue path above takes mutex_lock(&adev->dm.dc_lock)
the synchronous path in amdgpu_dm_atomic_commit_tail() (amdgpu_dm.c:10345)
takes spin_lock_irqsave(&pcrtc->dev->event_lock, ...) instead
Since dc_lock is a mutex and event_lock is a spinlock taken with IRQs disabled,
the synchronous path structurally can't take dc_lock (can't sleep under a
spinlock), so these two call sites don't mutually exclude each other. If both
can run concurrently on hardware under load (e.g. a mode-adjust racing with a
queued freesync vmin/vmax update), the REG_WAIT could be polling for a
det{N}_size value that gets superseded mid-wait by the other path — which would
explain why the escalating-count pattern gets worse over uptime rather than
being a fixed, deterministic timing margin issue. I haven't been able to
confirm this is the actual root cause (would need traced concurrent hits on
both paths under load, which I don't have tooling for), but it seemed worth
flagging given the "more liberal vmin/vmax update for freesync" patch
(6d31602a9f57, reverted for unrelated regressions) touched this same area.
As a low-risk experiment (does not address the lock question above, just
widens the timing margin) I tried bumping the REG_WAIT budget from 100
to 2000 tries at the same 1us interval - pure timeout widening, no logic
change. Haven't been able to verify yet whether it actually helps under
sustained load, will report back if I get a chance to test it properly.
Happy to run additional diagnostics if it'd help (dmesg during
reproduction, ftrace on the workqueue, etc.) - this is reproducing
reliably enough on my end that repeat testing isn't a problem.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2150776
Title:
Ubuntu 26.04 GNOME Wayland: random short display/presentation freezes
on AMD RX 7900 XT while apps continue running
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2150776/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
