All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Brost <matthew.brost@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	daniele.ceraolospurio@intel.com
Subject: Re: [Intel-gfx] [PATCH 08/27] drm/i915/selftests: Add a cancel request selftest that triggers a reset
Date: Thu, 26 Aug 2021 07:00:18 -0700	[thread overview]
Message-ID: <20210826140016.GA19362@jons-linux-dev-box> (raw)
In-Reply-To: <2aa468eb-e7a8-1617-1b92-7a8f8b6ae015@linux.intel.com>

On Thu, Aug 26, 2021 at 10:32:54AM +0100, Tvrtko Ursulin wrote:
> 
> On 26/08/2021 04:23, Matthew Brost wrote:
> > Add a cancel request selftest that results in an engine reset to cancel
> > the request as it is non-preemptable. Also insert a NOP request after
> > the cancelled request and confirm that it completely successfully.
> 
> Which patch fixes a problem this exposes in the execlists implementation?
> 

https://patchwork.freedesktop.org/patch/451421/?series=93704&rev=6

> > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > ---
> >   drivers/gpu/drm/i915/selftests/i915_request.c | 100 ++++++++++++++++++
> >   1 file changed, 100 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c b/drivers/gpu/drm/i915/selftests/i915_request.c
> > index d67710d10615..e2c5db77f087 100644
> > --- a/drivers/gpu/drm/i915/selftests/i915_request.c
> > +++ b/drivers/gpu/drm/i915/selftests/i915_request.c
> > @@ -772,6 +772,98 @@ static int __cancel_completed(struct intel_engine_cs *engine)
> >   	return err;
> >   }
> > +static int __cancel_reset(struct intel_engine_cs *engine)
> > +{
> > +	struct intel_context *ce;
> > +	struct igt_spinner spin;
> > +	struct i915_request *rq, *nop;
> > +	unsigned long preempt_timeout_ms;
> > +	int err = 0;
> > +
> 
> You may need to skip the test if preempt timeout is compiled out or if GPU
> reset is altogether disabled.
>

Yes, probably. Will fix this.
 
> > +	preempt_timeout_ms = engine->props.preempt_timeout_ms;
> > +	engine->props.preempt_timeout_ms = 100;
> > +
> > +	if (igt_spinner_init(&spin, engine->gt))
> > +		goto out_restore;
> > +
> > +	ce = intel_context_create(engine);
> > +	if (IS_ERR(ce)) {
> > +		err = PTR_ERR(ce);
> > +		goto out_spin;
> > +	}
> > +
> > +	rq = igt_spinner_create_request(&spin, ce, MI_NOOP);
> > +	if (IS_ERR(rq)) {
> > +		err = PTR_ERR(rq);
> > +		goto out_ce;
> > +	}
> > +
> > +	pr_debug("%s: Cancelling active request\n", engine->name);
> 
> "active non-preemptable" perhaps?
> 

Sure.

> > +	i915_request_get(rq);
> > +	i915_request_add(rq);
> > +	if (!igt_wait_for_spinner(&spin, rq)) {
> > +		struct drm_printer p = drm_info_printer(engine->i915->drm.dev);
> > +
> > +		pr_err("Failed to start spinner on %s\n", engine->name);
> > +		intel_engine_dump(engine, &p, "%s\n", engine->name);
> > +		err = -ETIME;
> > +		goto out_rq;
> > +	}
> > +
> > +	nop = intel_context_create_request(ce);
> > +	if (IS_ERR(nop))
> > +		goto out_nop;
> > +	i915_request_get(nop);
> > +	i915_request_add(nop);
> > +
> > +	i915_request_cancel(rq, -EINTR);
> > +
> > +	if (i915_request_wait(rq, 0, HZ) < 0) {
> > +		struct drm_printer p = drm_info_printer(engine->i915->drm.dev);
> > +
> > +		pr_err("%s: Failed to cancel hung request\n", engine->name);
> > +		intel_engine_dump(engine, &p, "%s\n", engine->name);
> > +		err = -ETIME;
> > +		goto out_nop;
> > +	}
> > +
> > +	if (rq->fence.error != -EINTR) {
> > +		pr_err("%s: fence not cancelled (%u)\n",
> > +		       engine->name, rq->fence.error);
> > +		err = -EINVAL;
> > +		goto out_nop;
> > +	}
> > +
> > +	if (i915_request_wait(nop, 0, HZ) < 0) {
> > +		struct drm_printer p = drm_info_printer(engine->i915->drm.dev);
> > +
> > +		pr_err("%s: Failed to complete nop request\n", engine->name);
> > +		intel_engine_dump(engine, &p, "%s\n", engine->name);
> > +		err = -ETIME;
> > +		goto out_nop;
> > +	}
> > +
> > +	if (nop->fence.error != 0) {
> > +		pr_err("%s: Nop request errored (%u)\n",
> 
> Maybe s/nop/innocent/ in the respective log messages?
> 

I kinda perfer NOP.

> > +		       engine->name, nop->fence.error);
> > +		err = -EINVAL;
> > +	}
> > +
> > +out_nop:
> > +	i915_request_put(nop);
> > +out_rq:
> > +	i915_request_put(rq);
> > +out_ce:
> > +	intel_context_put(ce);
> > +out_spin:
> > +	igt_spinner_fini(&spin);
> > +out_restore:
> > +	engine->props.preempt_timeout_ms = preempt_timeout_ms;
> > +	if (err)
> > +		pr_err("%s: %s error %d\n", __func__, engine->name, err);
> > +	return err;
> > +}
> > +
> >   static int live_cancel_request(void *arg)
> >   {
> >   	struct drm_i915_private *i915 = arg;
> > @@ -804,6 +896,14 @@ static int live_cancel_request(void *arg)
> >   			return err;
> >   		if (err2)
> >   			return err2;
> > +
> > +		/* Expects reset so call outside of igt_live_test_* */
> 
> Hm there are live tests like live_preempt_cancel which seemingly manage to
> do resets under the live test block.
>

You can increment t->reset_global if a GT reset is expected, problem is
only execlists do a GT while GuC submission does a GuC engine based
reset so we'd have to put in a statement like this if was within the
begin / end block:

if !guc
	t->reset_global++

I'd just rather leave it as is rather than baking in execlists / guc
backend specific knowledge into the test.

Matt

> Regards,
> 
> Tvrtko
> 
> > +		err = __cancel_reset(engine);
> > +		if (err)
> > +			return err;
> > +
> > +		if (igt_flush_test(i915))
> > +			return -EIO;
> >   	}
> >   	return 0;
> > 

  reply	other threads:[~2021-08-26 14:05 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-26  3:23 [Intel-gfx] [PATCH 00/27] Clean up GuC CI failures, simplify locking, and kernel DOC Matthew Brost
2021-08-26  3:23 ` Matthew Brost
2021-08-26  3:23 ` [Intel-gfx] [PATCH 01/27] drm/i915/guc: Fix blocked context accounting Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26  3:23 ` [Intel-gfx] [PATCH 02/27] drm/i915/guc: Fix outstanding G2H accounting Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26 23:09   ` [Intel-gfx] " Daniele Ceraolo Spurio
2021-08-26 23:09     ` Daniele Ceraolo Spurio
2021-08-27  1:36     ` [Intel-gfx] " Matthew Brost
2021-08-27  1:36       ` Matthew Brost
2021-08-26  3:23 ` [Intel-gfx] [PATCH 03/27] drm/i915/guc: Unwind context requests in reverse order Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26  3:23 ` [Intel-gfx] [PATCH 04/27] drm/i915/guc: Don't drop ce->guc_active.lock when unwinding context Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26  3:23 ` [Intel-gfx] [PATCH 05/27] drm/i915/guc: Process all G2H message at once in work queue Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26  3:23 ` [Intel-gfx] [PATCH 06/27] drm/i915/guc: Workaround reset G2H is received after schedule done G2H Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26 23:11   ` [Intel-gfx] " Daniele Ceraolo Spurio
2021-08-26 23:11     ` Daniele Ceraolo Spurio
2021-08-26  3:23 ` [Intel-gfx] [PATCH 07/27] Revert "drm/i915/gt: Propagate change in error status to children on unhold" Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26  3:23 ` [Intel-gfx] [PATCH 08/27] drm/i915/selftests: Add a cancel request selftest that triggers a reset Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26  9:32   ` [Intel-gfx] " Tvrtko Ursulin
2021-08-26 14:00     ` Matthew Brost [this message]
2021-08-26  3:23 ` [Intel-gfx] [PATCH 09/27] drm/i915/guc: Kick tasklet after queuing a request Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26  3:23 ` [Intel-gfx] [PATCH 10/27] drm/i915/guc: Don't enable scheduling on a banned context, guc_id invalid, not registered Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26  3:23 ` [Intel-gfx] [PATCH 11/27] drm/i915/guc: Copy whole golden context, set engine state size of subset Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26 23:21   ` [Intel-gfx] " Daniele Ceraolo Spurio
2021-08-26 23:21     ` Daniele Ceraolo Spurio
2021-08-26 23:33   ` [Intel-gfx] " John Harrison
2021-08-26  3:23 ` [Intel-gfx] [PATCH 12/27] drm/i915/selftests: Add initial GuC selftest for scrubbing lost G2H Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26  3:23 ` [Intel-gfx] [PATCH 13/27] drm/i915/guc: Take context ref when cancelling request Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26  3:23 ` [Intel-gfx] [PATCH 14/27] drm/i915/guc: Don't touch guc_state.sched_state without a lock Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26  3:23 ` [Intel-gfx] [PATCH 15/27] drm/i915/guc: Reset LRC descriptor if register returns -ENODEV Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26  3:23 ` [Intel-gfx] [PATCH 16/27] drm/i915: Allocate error capture in nowait context Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26 16:18   ` [Intel-gfx] " Matthew Brost
2021-08-26 16:21   ` Daniel Vetter
2021-08-26  3:23 ` [Intel-gfx] [PATCH 17/27] drm/i915/guc: Flush G2H work queue during reset Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26  3:23 ` [Intel-gfx] [PATCH 18/27] drm/i915/guc: Release submit fence from an irq_work Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26  3:23 ` [Intel-gfx] [PATCH 19/27] drm/i915/guc: Move guc_blocked fence to struct guc_state Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26  3:23 ` [Intel-gfx] [PATCH 20/27] drm/i915/guc: Rework and simplify locking Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26  3:23 ` [Intel-gfx] [PATCH 21/27] drm/i915/guc: Proper xarray usage for contexts_lookup Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26  3:23 ` [Intel-gfx] [PATCH 22/27] drm/i915/guc: Drop pin count check trick between sched_disable and re-pin Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26  3:23 ` [Intel-gfx] [PATCH 23/27] drm/i915/guc: Move GuC priority fields in context under guc_active Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26 23:26   ` [Intel-gfx] " Daniele Ceraolo Spurio
2021-08-26 23:26     ` Daniele Ceraolo Spurio
2021-08-26  3:23 ` [Intel-gfx] [PATCH 24/27] drm/i915/guc: Move fields protected by guc->contexts_lock into sub structure Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26  3:23 ` [Intel-gfx] [PATCH 25/27] drm/i915/guc: Drop guc_active move everything into guc_state Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-26  3:23 ` [Intel-gfx] [PATCH 26/27] drm/i915/guc: Add GuC kernel doc Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-31 19:04   ` [Intel-gfx] " John Harrison
2021-08-26  3:23 ` [Intel-gfx] [PATCH 27/27] drm/i915/guc: Drop static inline functions intel_guc_submission.c Matthew Brost
2021-08-26  3:23   ` Matthew Brost
2021-08-31 19:09   ` [Intel-gfx] " John Harrison
2021-08-26  4:43 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Clean up GuC CI failures, simplify locking, and kernel DOC (rev5) Patchwork
2021-08-26  4:45 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-08-26  5:14 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-08-26 10:34 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2021-08-26 17:56   ` Matthew Brost
2021-08-26 15:32 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Clean up GuC CI failures, simplify locking, and kernel DOC (rev6) Patchwork
2021-08-26 15:33 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-08-26 16:17 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2021-08-26 17:44   ` Matthew Brost
2021-08-26 19:20 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Clean up GuC CI failures, simplify locking, and kernel DOC (rev7) Patchwork
2021-08-26 19:21 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-08-26 19:50 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-08-27  4:22 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2021-08-19  6:16 [Intel-gfx] [PATCH 00/27] Clean up GuC CI failures, simplify locking, and kernel DOC Matthew Brost
2021-08-19  6:16 ` [Intel-gfx] [PATCH 08/27] drm/i915/selftests: Add a cancel request selftest that triggers a reset Matthew Brost

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=20210826140016.GA19362@jons-linux-dev-box \
    --to=matthew.brost@intel.com \
    --cc=daniele.ceraolospurio@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=tvrtko.ursulin@linux.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.