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 <[email protected]> To: Yunseong Kim <[email protected]> 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: ____________________________________________________________________________________________________________ Should be fixed with these patches: https://gitlab.freedesktop.org/agd5f/linux/-/commit/d094bc1f17783d148b8172339d05a12095e13dd4 https://gitlab.freedesktop.org/agd5f/linux/-/commit/d73f4e118dc4c688fe7d19883027d0ef14822c61 https://gitlab.freedesktop.org/agd5f/linux/-/commit/c9ab9622f5b2799fe624a4a134e60112149271dd ___________________________________________________________________________________________________________ I am not sure when these patches will make through a stable release of the kernel. Regardless, I've recently updated my Debian Kernel to version 7.1.3 from trixie-backports. No hangs or GPU issues so far, and it has been several weeks of stability even with the previous 7.0.13 kernel. Please, let me know if you still need me to do something else, now with this new info in hand. Best regards, -- Gabriel Elias de Aquino *[email protected]* ----- 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
