From: Dave Gordon <david.s.gordon@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2 1/3] drm/i915: Record the ringbuffer associated with the request
Date: Tue, 15 Dec 2015 16:53:13 +0000 [thread overview]
Message-ID: <56704579.5010305@intel.com> (raw)
In-Reply-To: <20151214112835.GN24300@nuc-i3427.alporthouse.com>
On 14/12/15 11:28, Chris Wilson wrote:
> On Mon, Dec 14, 2015 at 11:14:31AM +0000, Dave Gordon wrote:
>> On 11/12/15 22:59, Chris Wilson wrote:
>>> The request tells us where to read the ringbuf from, so use that
>>> information to simplify the error capture. If no request was active at
>>> the time of the hang, the ring is idle and there is no information
>>> inside the ring pertaining to the hang.
>>>
>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>> ---
>>> drivers/gpu/drm/i915/i915_gpu_error.c | 29 ++++++++++-------------------
>>> 1 file changed, 10 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c
>>> index 3e137fc701cf..6eefe9c36931 100644
>>> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
>>> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
>>> @@ -995,7 +995,7 @@ static void i915_gem_record_rings(struct drm_device *dev,
>>>
>>> for (i = 0; i < I915_NUM_RINGS; i++) {
>>> struct intel_engine_cs *ring = &dev_priv->ring[i];
>>> - struct intel_ringbuffer *rbuf;
>>> + struct intel_ringbuffer *rbuf = NULL;
>>>
>>> error->ring[i].pid = -1;
>>>
>>> @@ -1039,26 +1039,17 @@ static void i915_gem_record_rings(struct drm_device *dev,
>>> }
>>> rcu_read_unlock();
>>> }
>>> +
>>> + rbuf = request->ringbuf;
>>> }
>>>
>>> - if (i915.enable_execlists) {
>>> - /* TODO: This is only a small fix to keep basic error
>>> - * capture working, but we need to add more information
>>> - * for it to be useful (e.g. dump the context being
>>> - * executed).
>>> - */
>>> - if (request)
>>> - rbuf = request->ctx->engine[ring->id].ringbuf;
>>> - else
>>> - rbuf = ring->default_context->engine[ring->id].ringbuf;
>>> - } else
>>> - rbuf = ring->buffer;
>>> -
>>> - error->ring[i].cpu_ring_head = rbuf->head;
>>> - error->ring[i].cpu_ring_tail = rbuf->tail;
>>> -
>>> - error->ring[i].ringbuffer =
>>> - i915_error_ggtt_object_create(dev_priv, rbuf->obj);
>>> + if (rbuf) {
>>> + error->ring[i].cpu_ring_head = rbuf->head;
>>> + error->ring[i].cpu_ring_tail = rbuf->tail;
>>> + error->ring[i].ringbuffer =
>>> + i915_error_ggtt_object_create(dev_priv,
>>> + rbuf->obj);
>>> + }
>>>
>>> error->ring[i].hws_page =
>>> i915_error_ggtt_object_create(dev_priv, ring->status_page.obj);
>>
>> I think the code you deleted is intended to capture the *default*
>> ringbuffer if there is no request active -- sometimes we will switch
>> an engine to the default context (and therefore ringbuffer) when
>> there's no work to be done.
>
> So answer the question, why? I don't have a use for it. This code in
> particular is nothing more than a hack for execlists and in no way
> reflects my intentions for the postmortem debugging tool.
>
>> Another option that's sometimes useful is to capture the ringbuffer
>> pointed to by the START register. This helps in finding situations
>> where the driver and the GPU disagree about what should be in
>> progress.
>
> That is a possibitly, except is no more interesting than inspecting the
> START vs expected (and requires the stop_machine rework to walk the
> lists without crashing).
>
>> I've got a few patches that update some of the error capture that's
>> always been missing in execlist mode (like, actually capturing the
>> active context), and add some more decoding of what we do capture.
>
> No decoding. That is easier done in userspace. And I sent patches to do
> more capturing many, many months ago, along with fixing up most of the
> invalid ppgtt state.
> -Chris
Anyway, the removal of the unnecessary execlist/non-execlist is
worthwhile, so
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
and then maybe I'll rework the default and/or START capture on top of
this later.
.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
prev parent reply other threads:[~2015-12-15 16:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-11 22:59 [PATCH v2 1/3] drm/i915: Record the ringbuffer associated with the request Chris Wilson
2015-12-11 22:59 ` [PATCH v2 2/3] drm/i915: Allow userspace to request no-error-capture upon GPU hangs Chris Wilson
2015-12-15 16:59 ` Dave Gordon
2015-12-11 22:59 ` [PATCH v2 3/3] drm/i915: Clean up GPU hang message Chris Wilson
2015-12-14 11:28 ` Dave Gordon
2015-12-14 11:39 ` Chris Wilson
2015-12-14 13:45 ` Chris Wilson
2015-12-14 11:14 ` [PATCH v2 1/3] drm/i915: Record the ringbuffer associated with the request Dave Gordon
2015-12-14 11:28 ` Chris Wilson
2015-12-15 16:53 ` Dave Gordon [this message]
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=56704579.5010305@intel.com \
--to=david.s.gordon@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
/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.