#1142158 linux-image-7.0.13+deb13-amd64: This appears similar to #1104269 but affects a Radeon RX 9060 XT (RDNA4) on Debian 13 with kernel 7.0.13 from backports. Unlike earlier reports, the known workarounds (amdgpu.dcdebugmask=0x10, 0x12, amdgpu.runpm=0) do not mitigate the issue. In recent occurrences it required a hard reset. #1142158
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
Hi Gabriel, Thanks for updating. When you using Debian Kernel v7.1.3, then it resolve this issue without pcie_aspm=off workaround? Best regards, Yunseong-------- Forwarded Message -------- Subject: Re: linux-image-7.0.13+deb13-amd64: This appears similar to #1104269 but affects a Radeon RX 9060 XT (RDNA4) on Debian 13 with kernel 7.0.13 from backports. Unlike earlier reports, the known workarounds (amdgpu.dcdebugmask=0x10, 0x12, amdgpu.runpm=0) do not mitigate the issue. In recent occurrences it required a hard reset. Date: Thu, 06 Aug 2026 18:24:45 -0300 From: Gabriel Elias de Aquino <gabriel.aquino86@gmail.com> To: Yunseong Kim <ysk@kzalloc.com> Hi Yunseong, A few updates regarding this issue: 1. I've tried a new workaround and it completely solved the issue. No freezing and no hangs since. The workaround was pcie_aspm=off as a kernel parameter on boot. 2. I've also reported it directly to AMD and the amdgpu driver maintainer answered this:----- Mensagem original ----- 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
-------- Forwarded Message -------- Subject: Re: Fwd: linux-image-7.0.13+deb13-amd64: This appears similar to #1104269 but affects a Radeon RX 9060 XT (RDNA4) on Debian 13 with kernel 7.0.13 from backports. Unlike earlier reports, the known workarounds (amdgpu.dcdebugmask=0x10, 0x12, amdgpu.runpm=0) do not mitigate the issue. In recent occurrences it required a hard reset. Date: Wed, 12 Aug 2026 20:22:14 -0300 From: Gabriel Elias de Aquino <gabriel.aquino86@gmail.com> To: Yunseong Kim <ysk@kzalloc.com> Hi Yunseong, I didn't test it without the workaround yet, but I've received a new update from the amdgpu maintainer and he informed me that the issue was fixed in *6.18.44*, *7.1.8* and *7.2-rc7*. Guess I'll wait for the 7.1.8 version to be shipped in trixie-backports just in case. Best regards,
Hi Gabriel, Would it be an option/possible for you to rather just fetch the update from testing already so we can confirm it is fixed in 7.1.8? Otherwise, 7.1.8-1~bpo13+1 is pending to be processed. Regards, Salvatore
Hi Gabriel, 7.1.8-1~bpo13+1 is now as well available in trixie-backports, can you please test it and report back if the issue is fixed? Regards, Salvatore