From: "Mateo Lozano, Oscar" <oscar.mateo@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH v2] tests/gem_error_capture: Initial testcase for error state capture/dump
Date: Fri, 9 May 2014 12:07:04 +0000 [thread overview]
Message-ID: <1399636924.3469.5.camel@omateolo-linux2> (raw)
In-Reply-To: <20140415193827.GG1023@phenom.ffwll.local>
On Tue, 2014-04-15 at 21:38 +0200, Daniel Vetter wrote:
> On Mon, Apr 14, 2014 at 01:03:58PM +0000, Mateo Lozano, Oscar wrote:
> > > I would add a little more smarts to both the kernel and error-decode.
> > > In the kernel, we can print the guilty request, which you can then use to
> > > confirm that it is yours. That seems to me to be a stronger validation of
> > > gem_error_capture, and a useful bit of information from hangstats that we do
> > > not expose currently.
> >
> > That sounds good. I have to add a number of other things to
> > i915_gpu_error as part of the Execlists code, so I´ll add a "--- guilty
> > request" as well and resubmit this test together with the series.
>
> If we want this much smarts then we need a properly hanging batch, e.g.
> like the looping batch used in gem_reset_stats.
>
> The problem with that is that this will kill the gpu if reset doesn't work
> (i.e. gen2/3) so we need to skip this test there. Or maybe split things
> into 2 subtests and use the properly hanging batch only when we do the
> extended guilty testing under discussion here.
>
> But in any case just checking that the batch is somewhere in the ring
> (properly masking of lower bits 0-11 ofc) and checking whether the batch
> is correctl dumped (with the magic value) would catch a lot of the
> past&present execbuf bugs - we've had issues with dumping fancy values of
> 0 a lot.
>
> For the guilty stuff we have an extensive set of tests in gem_reset_stat
> using the reset stat ioctl already. And for the occasional "the hang
> detection logic is busted bug" I think nothing short of a human brain
> locking at the batch really helps. At least if we want to be somewhat
> platform agnostic ...
>
> So imo the current level of checking loosk Good Enough. But I'm certainly
> not going to stop you ;-)
Ok, for the moment I'm happy that I can unblock Execlists. I don't mind
looking at the "--- guilty requests" in the future, but first I need to
get Execlists out of the way...
Cheers,
Oscar
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2014-05-09 12:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-11 12:59 [PATCH] tests/gem_error_capture: Initial testcase for error state capture/dump oscar.mateo
2014-04-11 13:09 ` Mateo Lozano, Oscar
2014-04-11 14:27 ` Daniel Vetter
2014-04-11 16:48 ` [PATCH v2] " oscar.mateo
2014-04-11 17:12 ` Chris Wilson
2014-04-14 10:01 ` Mateo Lozano, Oscar
2014-04-14 10:14 ` Chris Wilson
2014-04-14 10:23 ` Mateo Lozano, Oscar
2014-04-14 10:30 ` Chris Wilson
2014-04-14 13:03 ` Mateo Lozano, Oscar
2014-04-15 19:38 ` Daniel Vetter
2014-05-09 12:07 ` Mateo Lozano, Oscar [this message]
2014-04-15 14:49 ` Mika Kuoppala
2014-05-09 12:04 ` Mateo Lozano, Oscar
2014-05-09 11:54 ` [PATCH] " oscar.mateo
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=1399636924.3469.5.camel@omateolo-linux2 \
--to=oscar.mateo@intel.com \
--cc=daniel@ffwll.ch \
--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.