From: Arun Siluvery <arun.siluvery@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
intel-gfx@lists.freedesktop.org,
Mika Kuoppala <mika.kuoppala@linux.intel.com>
Subject: Re: [PATCH 05/11] drm/i915/tdr: Identify hung request and drop it
Date: Wed, 27 Jul 2016 12:54:44 +0100 [thread overview]
Message-ID: <5798A104.7080006@linux.intel.com> (raw)
In-Reply-To: <20160726213718.GE31051@nuc-i3427.alporthouse.com>
On 26/07/2016 22:37, Chris Wilson wrote:
> On Tue, Jul 26, 2016 at 05:40:51PM +0100, Arun Siluvery wrote:
>> The current active request is the one that caused the hang so this is
>> retrieved and removed from elsp queue, otherwise we cannot submit other
>> workloads to be processed by GPU.
>>
>> A consistency check between HW and driver is performed to ensure that we
>> are dropping the correct request. Since this request doesn't get executed
>> anymore, we also need to advance the seqno to mark it as complete. Head
>> pointer is advanced to skip the offending batch so that HW resumes
>> execution other workloads. If HW and SW don't agree then we won't proceed
>> with engine reset, this is treated as an error condition and we fallback to
>> full gpu reset.
>>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
>> Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
>> ---
>> drivers/gpu/drm/i915/intel_lrc.c | 116 +++++++++++++++++++++++++++++++++++++++
>> drivers/gpu/drm/i915/intel_lrc.h | 2 +
>> 2 files changed, 118 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
>> index daf1279..8fc5a3b 100644
>> --- a/drivers/gpu/drm/i915/intel_lrc.c
>> +++ b/drivers/gpu/drm/i915/intel_lrc.c
>> @@ -1026,6 +1026,122 @@ void intel_lr_context_unpin(struct i915_gem_context *ctx,
>> i915_gem_context_put(ctx);
>> }
>>
>> +static void intel_lr_context_resync(struct i915_gem_context *ctx,
>> + struct intel_engine_cs *engine)
>> +{
>> + u32 head;
>> + u32 head_addr, tail_addr;
>> + u32 *reg_state;
>> + struct intel_ringbuffer *ringbuf;
>> + struct drm_i915_private *dev_priv = engine->i915;
>> +
>> + ringbuf = ctx->engine[engine->id].ringbuf;
>> + reg_state = ctx->engine[engine->id].lrc_reg_state;
>> +
>> + head = I915_READ_HEAD(engine);
>> + head_addr = head & HEAD_ADDR;
>> + tail_addr = reg_state[CTX_RING_TAIL+1] & TAIL_ADDR;
>
> ?
>
> We know where we want the head to be to emit the breadcrumb and complete
> the request since we can record that when constructing the request. That
> also neatly solves the riddle of how to update the hw state.
We want to skip only MI_BATCH_BUFFER_START and continue as usual so just
using existing info.
>
> resync? intel_lr_context_reset_ring may be more apt, or maybe
> intel_execlists_reset_request?
resync because we read current state and update it.
intel_execlists_reset_request() sounds better, will change it as
suggested. thanks.
regards
Arun
> -Chris
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-07-27 11:54 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-26 16:40 [PATCH 00/11] Execlist based Engine reset patches Arun Siluvery
2016-07-26 16:40 ` [PATCH 01/11] drm/i915: Update i915.reset to handle engine resets Arun Siluvery
2016-07-26 16:40 ` [PATCH 02/11] drm/i915: Separate out reset flags from the reset counter Arun Siluvery
2016-07-26 16:40 ` [PATCH 03/11] drm/i915/tdr: Update reset_in_progress to account for engine reset Arun Siluvery
2016-07-26 21:52 ` Chris Wilson
2016-07-27 11:16 ` Arun Siluvery
2016-07-27 11:41 ` Chris Wilson
2016-07-27 11:52 ` Arun Siluvery
2016-07-26 16:40 ` [PATCH 04/11] drm/i915/tdr: Modify error handler for per engine hang recovery Arun Siluvery
2016-07-26 16:40 ` [PATCH 05/11] drm/i915/tdr: Identify hung request and drop it Arun Siluvery
2016-07-26 21:37 ` Chris Wilson
2016-07-27 11:54 ` Arun Siluvery [this message]
2016-07-27 12:27 ` Chris Wilson
2016-07-27 21:35 ` Resubmitting requests following the hang Chris Wilson
2016-07-27 21:35 ` [PATCH 1/3] drm/i915: Record the position of the start of the request Chris Wilson
2016-07-27 21:35 ` [PATCH 2/3] lrc Chris Wilson
2016-07-27 21:36 ` [PATCH 3/3] reset-request-recovery Chris Wilson
2016-07-26 16:40 ` [PATCH 06/11] drm/i915/tdr: Restart submission after engine reset Arun Siluvery
2016-07-26 21:32 ` Chris Wilson
2016-07-26 16:40 ` [PATCH 07/11] drm/i915/tdr: Add support for per engine reset recovery Arun Siluvery
2016-07-26 21:51 ` Chris Wilson
2016-07-27 11:49 ` Arun Siluvery
2016-07-26 16:40 ` [PATCH 08/11] drm/i915: Skip reset request if there is one already Arun Siluvery
2016-07-26 16:40 ` [PATCH 09/11] drm/i915/tdr: Add engine reset count to error state Arun Siluvery
2016-07-26 16:40 ` [PATCH 10/11] drm/i915/tdr: Export reset count info to debugfs Arun Siluvery
2016-07-26 16:40 ` [PATCH 11/11] drm/i915/tdr: Enable Engine reset and recovery support Arun Siluvery
2016-07-26 17:11 ` ✗ Ro.CI.BAT: failure for Execlist based Engine reset patches Patchwork
2016-07-28 5:40 ` ✗ Ro.CI.BAT: failure for Execlist based Engine reset patches (rev4) 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=5798A104.7080006@linux.intel.com \
--to=arun.siluvery@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
--cc=mika.kuoppala@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.