From: Huang Rui <ray.huang@amd.com>
To: Jiqian Chen <Jiqian.Chen@amd.com>
Cc: "Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
amd-gfx@lists.freedesktop.org,
"Timur Kristóf" <timur.kristof@gmail.com>,
"Samuel Pitoiset" <samuel.pitoiset@gmail.com>,
"Tvrtko Ursulin" <tvrtko.ursulin@igalia.com>,
"Huang Trigger" <Trigger.Huang@amd.com>
Subject: Re: [PATCH v2 1/1] drm/amdgpu/gfx9: Fix Ring and IB test fail after mode2
Date: Thu, 11 Jun 2026 14:26:52 +0800 [thread overview]
Message-ID: <aipVLOVnOxst+zTS@amd.com> (raw)
In-Reply-To: <20260611055715.1142135-1-Jiqian.Chen@amd.com>
On Thu, Jun 11, 2026 at 01:57:15PM +0800, Jiqian Chen wrote:
> For Renior APU with gfx9, in some test scenarios with disabling
> ring_reset, like accessing an unmapped invalid address, it can
> trigger a gpu job timeout event, then driver uses Mode2 reset
> to reset GPU, but after Mode2 compute Ring test and IB test fail
> randomly. It because the CPC and CPF are still stuck after Mode2,
> that causes compute Ring test fail. What's more, the HQDs of
> MECs are still active, that causes MECs use stale HQDs when MECs
> are unhalted before driver restore MQDs, then causes compute IB
> tests fail.
>
> So, add sequences to reset CPC and CPF after Mode2, and de-active
> HQDs of MECs before unhalting MECs.
>
> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
> ---
> v1->v2 changes:
> * Move my sequences into a new function gfx_v9_0_cp_mode2_clear_state
> * Add reset Mode2 method check to the if condition that call my sequences
>
> v1:
> Hi all,
>
> My board is Renior APU with gfx9, smu12. I run a testcase that
> accesses an invalid address to trigger a amdgpu_job_timedout()
> with disabling ring_reset, so that driver will call mode2 reset
> directly. After mode2 reset I found compute Ring tests and compute
> IB tests fail randomly on random compute ring.
>
> We checked the scan dump of GPU, we can see the CPC and CPF are
> still stuck, that caused Compute Ring tests fail.
>
> I added printings in driver codes (gfx_v9_0_cp_resume), and found
> the HQDs of MECs are still active, that may cause MECs use stale
> HQDs when MECs are unhalted before mapping compute queues (restoring
> MQDs to HQDs).
>
> So, I send this patch to fix above problems.
> There are two main changes of my patch:
> One is to reset CPC and CPF before resuming KCQ.
> Another is to disable HQDs beofre unhalting MECs.
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 44 +++++++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> index 47721d0c3781..d3ef45aa299a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> @@ -3942,6 +3942,46 @@ static int gfx_v9_0_kcq_resume(struct amdgpu_device *adev)
> return amdgpu_gfx_enable_kcq(adev, 0);
> }
>
> +static void gfx_v9_0_cp_mode2_clear_state(struct amdgpu_device *adev)
> +{
> + u32 tmp;
> + int i, j, k;
> +
> + /*
> + * CPC and CPF are still stuck after Mode2 reset, that causes later
> + * compute ring test fail and then loop Mode2 reset infinitely
> + */
> + tmp = RREG32_SOC15(GC, 0, mmGRBM_SOFT_RESET);
> + tmp = REG_SET_FIELD(tmp, GRBM_SOFT_RESET, SOFT_RESET_CPC, 1);
> + tmp = REG_SET_FIELD(tmp, GRBM_SOFT_RESET, SOFT_RESET_CPF, 1);
> + WREG32_SOC15(GC, 0, mmGRBM_SOFT_RESET, tmp);
> + tmp = RREG32_SOC15(GC, 0, mmGRBM_SOFT_RESET);
> + udelay(50);
> +
> + tmp &= ~(GRBM_SOFT_RESET__SOFT_RESET_CPC_MASK |
> + GRBM_SOFT_RESET__SOFT_RESET_CPF_MASK);
> + WREG32_SOC15(GC, 0, mmGRBM_SOFT_RESET, tmp);
> + tmp = RREG32_SOC15(GC, 0, mmGRBM_SOFT_RESET);
> + udelay(50);
> +
> + /*
> + * CP_HQD_ACTIVE survives Mode2 reset. Deactivate every MEC HQD to
> + * prevent MEC use stale HQD when MEC unhalted before restoring MQD.
> + * Otherwise, later compute IB test may fail
> + */
> + for (i = 0; i < adev->gfx.mec.num_mec; i++) {
> + for (j = 0; j < adev->gfx.mec.num_pipe_per_mec; j++) {
> + for (k = 0; k < adev->gfx.mec.num_queue_per_pipe; k++) {
> + mutex_lock(&adev->srbm_mutex);
> + soc15_grbm_select(adev, i + 1, j, k, 0, 0);
> + WREG32_SOC15_RLC(GC, 0, mmCP_HQD_ACTIVE, 0);
I think we don't need to use WREG32_SOC15_RLC here, because SRIOV GPU won't
access this code path.
> + soc15_grbm_select(adev, 0, 0, 0, 0, 0);
> + mutex_unlock(&adev->srbm_mutex);
> + }
> + }
> + }
> +}
> +
> static int gfx_v9_0_cp_resume(struct amdgpu_device *adev)
> {
> int r, i;
> @@ -3967,6 +4007,10 @@ static int gfx_v9_0_cp_resume(struct amdgpu_device *adev)
> gfx_v9_0_cp_gfx_enable(adev, false);
> gfx_v9_0_cp_compute_enable(adev, false);
>
> + if ((adev->flags & AMD_IS_APU) && amdgpu_in_reset(adev) &&
> + amdgpu_asic_reset_method(adev) == AMD_RESET_METHOD_MODE2)
If we constrain the condition to a mode2 reset, does that mean we no longer
need to restrict it to APU?
Thanks,
Ray
> + gfx_v9_0_cp_mode2_clear_state(adev);
> +
> r = gfx_v9_0_kiq_resume(adev);
> if (r)
> return r;
> --
> 2.39.5
>
next prev parent reply other threads:[~2026-06-11 6:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-11 5:57 [PATCH v2 1/1] drm/amdgpu/gfx9: Fix Ring and IB test fail after mode2 Jiqian Chen
2026-06-11 6:26 ` Huang Rui [this message]
2026-06-11 7:09 ` Lazar, Lijo
2026-06-11 7:42 ` Huang Rui
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aipVLOVnOxst+zTS@amd.com \
--to=ray.huang@amd.com \
--cc=Jiqian.Chen@amd.com \
--cc=Trigger.Huang@amd.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=samuel.pitoiset@gmail.com \
--cc=timur.kristof@gmail.com \
--cc=tvrtko.ursulin@igalia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.