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>,
Dave Gordon <david.s.gordon@intel.com>
Subject: Re: [PATCH 2/5] drm/i915/error: capture ringbuffer pointed to by START
Date: Mon, 1 Feb 2016 21:30:00 +0000 [thread overview]
Message-ID: <56AFCE58.9010406@linux.intel.com> (raw)
In-Reply-To: <20160129114709.GK24534@nuc-i3427.alporthouse.com>
On 29/01/2016 11:47, Chris Wilson wrote:
> On Thu, Jan 28, 2016 at 07:01:21PM +0000, Arun Siluvery wrote:
>> From: Dave Gordon <david.s.gordon@intel.com>
>>
>> For: VIZ-2021
>> Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
>
> What information does this actually provide over and above the hw is not
> executing the ring we expect? How have you used this, how do you plan
> to?
Most of the times this matches with the ringbuffer we dump but when
there is inconsistency it helps to know what hw is actually executing as
opposed to what we expect, otherwise the head, tail values we capture
and the instructions at those offsets don't make sense. Without this we
don't have any idea what the HW was doing and what caused hang.
regards
Arun
>
> As it stands adding more fragile loops is just increasing the potential
> for an OOPS in that code, even more so as we can eliminate the current
> dangerous list iteration for extracting the current ctx object.
> -Chris
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-02-01 21:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-28 19:01 [PATCH 0/5] Capture more useful details in error state Arun Siluvery
2016-01-28 19:01 ` [PATCH 1/5] drm/i915/error: capture execlist state on error Arun Siluvery
2016-01-29 7:49 ` Mika Kuoppala
2016-01-29 11:45 ` Chris Wilson
2016-01-29 12:25 ` Arun Siluvery
2016-01-29 12:38 ` Chris Wilson
2016-01-28 19:01 ` [PATCH 2/5] drm/i915/error: capture ringbuffer pointed to by START Arun Siluvery
2016-01-29 11:47 ` Chris Wilson
2016-02-01 21:30 ` Arun Siluvery [this message]
2016-01-28 19:01 ` [PATCH 3/5] drm/i915/error: report ctx id & desc for each request in the queue Arun Siluvery
2016-01-29 8:17 ` Mika Kuoppala
2016-01-29 9:48 ` Arun Siluvery
2016-01-28 19:01 ` [PATCH 4/5] drm/i915/error: improve CSB reporting Arun Siluvery
2016-01-28 19:01 ` [PATCH 5/5] drm/i915/error: Capture WA ctx batch in error state Arun Siluvery
2016-01-29 7:52 ` Mika Kuoppala
2016-01-29 10:09 ` Arun Siluvery
2016-01-29 10:59 ` ✗ Fi.CI.BAT: failure for Capture more useful details " 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=56AFCE58.9010406@linux.intel.com \
--to=arun.siluvery@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=david.s.gordon@intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).