Re: [PATCH v6 2/2] drm/amd/display: add DMU timeout recovery support

[Hamza Mahfooz <someguy@effective-light.com>]

On Fri, Jul 17, 2026 at 04:41:44PM +0300, LetsDank wrote:
> Hi,
> 
> I have been seeing what appears to be the same failure on an MSI Bravo
> 15 C7VF with a Ryzen 5 7535HS / Rembrandt Radeon 660M (1002:1681), an
> internal 1920x1080 144 Hz eDP panel, and KDE X11. It occurred on Fedora
> kernels 6.19 and 7.1.3. The relevant signatures included:
> 
>   flip_done timed out
>   commit wait timed out
>   Error queueing DMUB command: status=2
> 
> Using amdgpu.dcdebugmask=0x810 has avoided the failure for more than 53
> hours across four boots, including one continuous run longer than 27
> hours.
> 
> I built this v6 series on top of v7.2-rc3 and booted it with:
> 
>   amdgpu.dcdebugmask=0 amdgpu.gpu_recovery=1
> 
> It passed five DPMS off/on cycles, five modeset cycles between 60 Hz and
> 144 Hz, and a short fullscreen rendering test. It then ran a normal KDE
> X11 workload for about 12.5 hours without any DMUB queue-full, DMCUB, or
> page-flip timeout message.
> 
> The original intermittent timeout did not occur during that run, so I
> cannot offer a Tested-by for the recovery path.
> 
> After about 12.5 hours the test kernel hit a separate gfxhub VM page
> fault attributed to Xorg, followed by a gfx_0.0.0 ring timeout and a
> successful ring reset. Mesa then aborted Xorg. There were no DMUB,
> DMCUB, or flip timeout messages in that incident. I preserved the full
> AMDGPU devcoredump and symbolized userspace coredumps if they would be
> useful as a separate report.
> 
> Patch 1 also needed a small API adaptation on v7.2-rc3 from
> drm_atomic_state and drm_atomic_state_*() to drm_atomic_commit and
> drm_atomic_commit_*(). The resulting kernel built cleanly, and all three
> commits passed checkpatch.pl --strict. I can send that fixup if it would
> help with a respin.
> 
> Is this series still being worked on, and would testing a revised version
> on this Rembrandt system be useful?

I haven't had much time to work on this, though if you look at the
previous thread [1] the whole idea around having a recovery path for KMS
was NACKed by Ville. So, it doesn't appear to me that there is much of
an appetite for this.

[1] https://lore.kernel.org/r/afuMqXoBt2oIFRm9@intel.com/
> 
> Regards,
> LetsDank
>