From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from MTA-10-3.privateemail.com (mta-10-3.privateemail.com [198.54.127.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E9560417D71 for ; Mon, 20 Jul 2026 12:32:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.54.127.62 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784550738; cv=none; b=LRFlVSgrVFjR543cfW+Jk0cKc/wsOGHI3NKtHa/3i/GG0MVE2/nYXS6fcDozboVqjjYXX5p4Y7RLXfutODQq8whKrjZ9gdh5TGN0ROvjVRRZVuyekF3QpNDfh2pD09sroGJnOyZb8hIB5x2qchMRIKNHXgQFAG2PGc4pFbB3Swk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784550738; c=relaxed/simple; bh=8cljvNY3tfK/TZ8Zs6pAmcIW4JAF24hNmWc/E+14vbM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Izl+UDj+iVjQwHG7DQCMSvBSTQT40ztg6w27p1Wwx1ieSHqMt7u0RQCGGdiYG49lY0O+Bha8POourOHLd/ufCKVSYn9oj8RtPHGqSIZttGgv2/cukfUwozROgsQbdWcTd+E/geGwFReJPWt2liMk17U3zFwKmqHrV302U/RURp4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=effective-light.com; spf=pass smtp.mailfrom=effective-light.com; arc=none smtp.client-ip=198.54.127.62 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=effective-light.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=effective-light.com Received: from mail.privateemail.com (K8S-PROD-WORKER-10 [142.188.184.102]) by mta-10.privateemail.com (Postfix) with ESMTPA id 4h3fzD0NJlz3hhTX; Mon, 20 Jul 2026 08:32:07 -0400 (EDT) Date: Mon, 20 Jul 2026 08:32:04 -0400 From: Hamza Mahfooz To: LetsDank Cc: Leo Li , Mario Limonciello , Harry Wentland , amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v6 2/2] drm/amd/display: add DMU timeout recovery support Message-ID: References: <20260505182105.420525-1-someguy@effective-light.com> <20260505182105.420525-2-someguy@effective-light.com> <178429570497.694276.1089609041510474786.dmub-recovery-v6-test@icloud.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <178429570497.694276.1089609041510474786.dmub-recovery-v6-test@icloud.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 >