From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
Chris Wilson <chris@chris-wilson.co.uk>,
intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/3] drm/i915: Complete requests in nop_submit_request
Date: Fri, 18 Nov 2016 15:03:21 +0200 [thread overview]
Message-ID: <87poltuehy.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <98eb8861-17df-3374-0c12-b3766c1661dd@linux.intel.com>
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> writes:
> On 18/11/2016 09:37, Chris Wilson wrote:
>> Since the submit/execute split in commit d55ac5bf97c6 ("drm/i915: Defer
>> transfer onto execution timeline to actual hw submission") the
>> global seqno advance was deferred until the submit_request callback.
>> After wedging the GPU, we were installing a nop_submit_request handler
>> (to avoid waking up the dead hw) but I had missed converting this over
>> to the new scheme. Under the new scheme, we have to explicitly call
>> i915_gem_submit_request() from the submit_request handler to mark the
>> request as on the hardware. If we don't the request is always pending,
>> and any waiter will continue to wait indefinitely and hangcheck will not
>> be able to resolve the lockup.
>>
>> References: https://bugs.freedesktop.org/show_bug.cgi?id=98748
>> Testcase: igt/gem_eio/in-flight
>> Fixes: d55ac5bf97c6 ("drm/i915: Defer transfer onto execution timeline to actual hw submission")
>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> ---
>> drivers/gpu/drm/i915/i915_gem.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
>> index 7b9f5b99b0f3..7037a8b26903 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> @@ -2762,6 +2762,8 @@ void i915_gem_reset(struct drm_i915_private *dev_priv)
>>
>> static void nop_submit_request(struct drm_i915_gem_request *request)
>> {
>> + i915_gem_request_submit(request);
>> + intel_engine_init_global_seqno(request->engine, request->global_seqno);
>
> Slight deja vu but not sure - we don't have a way of marking these as
> failed so what happens in practice here? This as at the point of no
> return, no replay, or allowing the context to recover or something?
>
I have another question. If we do this, why not
do it (also) when we prepare to start in the postfix of failed
request.
In another words, write the seqno with mmio, and start
replay not in the postfi, but at the start of next whole request?
-Mika
>> }
>>
>> static void i915_gem_cleanup_engine(struct intel_engine_cs *engine)
>>
>
> Regards,
>
> Tvrtko
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-11-18 13:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-18 9:37 [PATCH 1/3] drm/i915: Disable hangcheck when wedged Chris Wilson
2016-11-18 9:37 ` [PATCH 2/3] drm/i915: Complete requests in nop_submit_request Chris Wilson
2016-11-18 12:56 ` Tvrtko Ursulin
2016-11-18 13:03 ` Mika Kuoppala [this message]
2016-11-18 13:33 ` Chris Wilson
2016-11-18 14:22 ` Tvrtko Ursulin
2016-11-18 9:37 ` [PATCH 3/3] drm/i915: Stop the machine as we install the wedged submit_request handler Chris Wilson
2016-11-18 14:38 ` Chris Wilson
2016-11-21 12:40 ` [PATCH v2] " Chris Wilson
2016-11-22 14:07 ` Mika Kuoppala
2016-11-18 10:16 ` ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Disable hangcheck when wedged Patchwork
2016-11-18 11:40 ` [PATCH 1/3] " Mika Kuoppala
2016-11-21 16:45 ` ✗ Fi.CI.BAT: warning for series starting with [1/3] drm/i915: Disable hangcheck when wedged (rev2) 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=87poltuehy.fsf@gaia.fi.intel.com \
--to=mika.kuoppala@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--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.