Control: tags -1 + moreinfo
Hi Gabriel,
Thanks for the detailed logs. From journal.txt this is a display-controller
(DCN) hang rather than a full GPU hang: at 22:26:31 page flips stop
completing, vblank interrupts stop ("vblank wait timed out on crtc 0"), and
there is no ring timeout or page fault anywhere in the log. amdgpu's reset
logic is only triggered by job timeouts on the compute/graphics rings, so a
pure display hang never triggers recovery — the system keeps running with a
dead screen until you hard-reset, exactly as you observed.
This also explains why the workarounds from #1104269 don't help:
amdgpu.dcdebugmask=0x10/0x12 only disable PSR (Panel Self Refresh), which
is an eDP laptop-panel feature and never active on your DisplayPort
monitor, and amdgpu.runpm=0 doesn't affect this path either. So your issue
appears to be a different, RDNA4-specific bug with a similar symptom.
Could you help us with the following, roughly in this order:
1. Let us know how often the hang occurs and whether it correlates with
anything: video calls/playback, screen lock/unlock, long uptime. The
logged hang happened during a Discord video call on a 144 Hz
VRR-capable monitor.
2. Try a newer kernel — linux-image-amd64 from experimental (7.2-rc), or
the newest available backport. RDNA4 display fixes are still landing
continuously. If it still reproduces there, this should be reported
upstream at https://gitlab.freedesktop.org/drm/amd/-/issues (we can
help forward it).
3. Workarounds that actually apply to your setup, tested one at a time:
a) Disable VRR: KDE System Settings -> Display -> Adaptive Sync =
"Never"
b) amdgpu.dcdebugmask=0x40 (disable multi-plane overlay)
c) amdgpu.dcdebugmask=0x2 (disable memory stutter mode)
d) amdgpu.dcdebugmask=0x8 (disable DC clock gating)
Please report which, if any, of these avoids the hang.
4. Next time it hangs, please don't hard-reset immediately — your system
is still alive, only the display is dead. SSH in from another machine
and capture:
dmesg
sudo cat /sys/kernel/debug/dri/*/amdgpu_dm_dtn_log
sudo cat /sys/kernel/debug/dri/*/amdgpu_fence_info
then try a manual reset and tell us whether the display comes back:
echo 1 | sudo tee /sys/kernel/debug/dri/*/amdgpu_gpu_recover
The amdgpu_dm_dtn_log captured while the display is hung is the single
most useful piece of data for the AMD display developers.
5. If possible, reproduce the hang once without the out-of-tree VMware
modules (vmmon/vmnet) loaded, so we can rule out the taint.
6. Finally: did any earlier kernel run reliably with this card (e.g. an
earlier 7.0.x point release)? A bisect is only practical if we have a
known-good version and a way to reproduce the hang on demand, so the
items above come first.
Regards,
Yunseong
