From: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
To: <John.C.Harrison@intel.com>
Cc: Intel-GFX@lists.freedesktop.org, DRI-Devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: Look for a guilty context when an engine reset fails
Date: Mon, 12 Dec 2022 18:00:23 -0800 [thread overview]
Message-ID: <Y5fct8rRG/n09gP8@unerlige-ril> (raw)
In-Reply-To: <20221129211253.3183480-3-John.C.Harrison@Intel.com>
On Tue, Nov 29, 2022 at 01:12:53PM -0800, John.C.Harrison@Intel.com wrote:
>From: John Harrison <John.C.Harrison@Intel.com>
>
>Engine resets are supposed to never happen. But in the case when one
>does (due to unknwon reasons that normally come down to a missing
>w/a), it is useful to get as much information out of the system as
>possible. Given that the GuC effectively dies on such a situation, it
>is not possible to get a guilty context notification back. So do a
>manual search instead. Given that GuC is dead, this is safe because
>GuC won't be changing the engine state asynchronously.
>
>Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>---
> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>index 0a42f1807f52c..c82730804a1c4 100644
>--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>@@ -4751,11 +4751,24 @@ static void reset_fail_worker_func(struct work_struct *w)
> guc->submission_state.reset_fail_mask = 0;
> spin_unlock_irqrestore(&guc->submission_state.lock, flags);
>
>- if (likely(reset_fail_mask))
>+ if (likely(reset_fail_mask)) {
>+ struct intel_engine_cs *engine;
>+ enum intel_engine_id id;
>+
>+ /*
>+ * GuC is toast at this point - it dead loops after sending the failed
>+ * reset notification. So need to manually determine the guilty context.
>+ * Note that it should be safe/reliable to do this here because the GuC
>+ * is toast and will not be scheduling behind the KMD's back.
>+ */
Is that defined by the kmd-GuC interface that following a failed reset notification, GuC
will always dead-loop OR not schedule anything (even on other engines) until KMD takes
some action? What action should KMD take?
Regards,
Umesh
>+ for_each_engine_masked(engine, gt, reset_fail_mask, id)
>+ intel_guc_find_hung_context(engine);
>+
> intel_gt_handle_error(gt, reset_fail_mask,
> I915_ERROR_CAPTURE,
> "GuC failed to reset engine mask=0x%x\n",
> reset_fail_mask);
>+ }
> }
>
> int intel_guc_engine_failure_process_msg(struct intel_guc *guc,
>--
>2.37.3
>
WARNING: multiple messages have this Message-ID (diff)
From: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
To: <John.C.Harrison@intel.com>
Cc: Intel-GFX@lists.freedesktop.org, DRI-Devel@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/i915/guc: Look for a guilty context when an engine reset fails
Date: Mon, 12 Dec 2022 18:00:23 -0800 [thread overview]
Message-ID: <Y5fct8rRG/n09gP8@unerlige-ril> (raw)
In-Reply-To: <20221129211253.3183480-3-John.C.Harrison@Intel.com>
On Tue, Nov 29, 2022 at 01:12:53PM -0800, John.C.Harrison@Intel.com wrote:
>From: John Harrison <John.C.Harrison@Intel.com>
>
>Engine resets are supposed to never happen. But in the case when one
>does (due to unknwon reasons that normally come down to a missing
>w/a), it is useful to get as much information out of the system as
>possible. Given that the GuC effectively dies on such a situation, it
>is not possible to get a guilty context notification back. So do a
>manual search instead. Given that GuC is dead, this is safe because
>GuC won't be changing the engine state asynchronously.
>
>Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>---
> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>index 0a42f1807f52c..c82730804a1c4 100644
>--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>@@ -4751,11 +4751,24 @@ static void reset_fail_worker_func(struct work_struct *w)
> guc->submission_state.reset_fail_mask = 0;
> spin_unlock_irqrestore(&guc->submission_state.lock, flags);
>
>- if (likely(reset_fail_mask))
>+ if (likely(reset_fail_mask)) {
>+ struct intel_engine_cs *engine;
>+ enum intel_engine_id id;
>+
>+ /*
>+ * GuC is toast at this point - it dead loops after sending the failed
>+ * reset notification. So need to manually determine the guilty context.
>+ * Note that it should be safe/reliable to do this here because the GuC
>+ * is toast and will not be scheduling behind the KMD's back.
>+ */
Is that defined by the kmd-GuC interface that following a failed reset notification, GuC
will always dead-loop OR not schedule anything (even on other engines) until KMD takes
some action? What action should KMD take?
Regards,
Umesh
>+ for_each_engine_masked(engine, gt, reset_fail_mask, id)
>+ intel_guc_find_hung_context(engine);
>+
> intel_gt_handle_error(gt, reset_fail_mask,
> I915_ERROR_CAPTURE,
> "GuC failed to reset engine mask=0x%x\n",
> reset_fail_mask);
>+ }
> }
>
> int intel_guc_engine_failure_process_msg(struct intel_guc *guc,
>--
>2.37.3
>
next prev parent reply other threads:[~2022-12-13 2:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-29 21:12 [Intel-gfx] [PATCH 0/2] Allow error capture without a request / on reset failure John.C.Harrison
2022-11-29 21:12 ` John.C.Harrison
2022-11-29 21:12 ` [Intel-gfx] [PATCH 1/2] drm/i915: Allow error capture without a request John.C.Harrison
2022-11-29 21:12 ` John.C.Harrison
2022-12-13 1:52 ` [Intel-gfx] " Umesh Nerlige Ramappa
2022-12-16 21:06 ` John Harrison
2022-11-29 21:12 ` [Intel-gfx] [PATCH 2/2] drm/i915/guc: Look for a guilty context when an engine reset fails John.C.Harrison
2022-11-29 21:12 ` John.C.Harrison
2022-11-30 8:30 ` [Intel-gfx] " Tvrtko Ursulin
2022-11-30 21:04 ` John Harrison
2022-12-01 10:21 ` Tvrtko Ursulin
2022-12-13 2:00 ` Umesh Nerlige Ramappa [this message]
2022-12-13 2:00 ` Umesh Nerlige Ramappa
2022-11-30 0:08 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Allow error capture without a request / on reset failure Patchwork
2022-11-30 1:27 ` [Intel-gfx] ✗ Fi.CI.BAT: 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=Y5fct8rRG/n09gP8@unerlige-ril \
--to=umesh.nerlige.ramappa@intel.com \
--cc=DRI-Devel@lists.freedesktop.org \
--cc=Intel-GFX@lists.freedesktop.org \
--cc=John.C.Harrison@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 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.