From: Matthew Brost <matthew.brost@intel.com>
To: Jonathan Cavitt <jonathan.cavitt@intel.com>
Cc: <intel-xe@lists.freedesktop.org>, <saurabhg.gupta@intel.com>,
<john.c.harrison@intel.com>, <stuart.summers@intel.com>
Subject: Re: [PATCH] drm/xe/xe_guc_submit: Declare reset if guc stopped
Date: Mon, 3 Jun 2024 22:39:55 +0000 [thread overview]
Message-ID: <Zl5GO9ETvpzwfwbs@DUT025-TGLU.fm.intel.com> (raw)
In-Reply-To: <20240603210554.2458942-1-jonathan.cavitt@intel.com>
On Mon, Jun 03, 2024 at 02:05:54PM -0700, Jonathan Cavitt wrote:
> An exec queue should be considered reset if the guc it was running on
> has had its submission state disabled, as this normally only occurs on
> a reset. So, add the condition to the reset_status guc_exec_queue_op.
>
> Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
> CC: John Harrison <john.c.harrison@intel.com>
> CC: Matthew Brost <matthew.brost@intel.com>
> CC: Stuart Summers <stuart.summers@intel.com>
> ---
> drivers/gpu/drm/xe/xe_guc_submit.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c b/drivers/gpu/drm/xe/xe_guc_submit.c
> index d9c159e3c5320..8c0b0c70fa5ea 100644
> --- a/drivers/gpu/drm/xe/xe_guc_submit.c
> +++ b/drivers/gpu/drm/xe/xe_guc_submit.c
> @@ -1414,7 +1414,8 @@ static void guc_exec_queue_resume(struct xe_exec_queue *q)
>
> static bool guc_exec_queue_reset_status(struct xe_exec_queue *q)
> {
> - return exec_queue_reset(q) || exec_queue_killed_or_banned_or_wedged(q);
> + return guc_read_stopped(exec_queue_to_guc(q)) ||
I haven't wrapped my head around this issue completely but will take an
in depth look shortly but this patch is not correct. We only ban exec
queues which have jobs started but not completed during GT reset whereas
this patch will report all exec queues as reset during a period of time
when GuC submission is stopped (e.g. during a GT reset all exec queues
will being reset).
Matt
> + exec_queue_reset(q) || exec_queue_killed_or_banned_or_wedged(q);
> }
>
> /*
> --
> 2.25.1
>
next prev parent reply other threads:[~2024-06-03 22:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-03 21:05 [PATCH] drm/xe/xe_guc_submit: Declare reset if guc stopped Jonathan Cavitt
2024-06-03 22:39 ` Matthew Brost [this message]
2024-06-04 15:00 ` Cavitt, Jonathan
2024-06-04 22:00 ` ✓ CI.Patch_applied: success for " Patchwork
2024-06-04 22:00 ` ✓ CI.checkpatch: " Patchwork
2024-06-04 22:01 ` ✓ CI.KUnit: " Patchwork
2024-06-04 22:12 ` ✓ CI.Build: " Patchwork
2024-06-04 22:13 ` ✗ CI.Hooks: failure " Patchwork
2024-06-04 22:14 ` ✓ CI.checksparse: success " Patchwork
2024-06-04 22:42 ` ✓ CI.BAT: " Patchwork
2024-06-05 5:43 ` ✗ CI.FULL: failure " Patchwork
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=Zl5GO9ETvpzwfwbs@DUT025-TGLU.fm.intel.com \
--to=matthew.brost@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=john.c.harrison@intel.com \
--cc=jonathan.cavitt@intel.com \
--cc=saurabhg.gupta@intel.com \
--cc=stuart.summers@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox