All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Gore, Tim" <tim.gore@intel.com>
Cc: "mika.kuoppala@linux.com" <mika.kuoppala@linux.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"Wood, Thomas" <thomas.wood@intel.com>
Subject: Re: [PATCH i-g-t] tests/gem_reset_stats.c: prepare for per engine resets
Date: Wed, 18 Nov 2015 15:12:05 +0100	[thread overview]
Message-ID: <20151118141205.GT20799@phenom.ffwll.local> (raw)
In-Reply-To: <8FCC70911F3E9548866CA0E51893BCC32FA2B56F@irsmsx105.ger.corp.intel.com>

On Wed, Nov 18, 2015 at 12:15:11PM +0000, Gore, Tim wrote:
> 
> 
> Tim Gore 
> Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
> 
> 
> > -----Original Message-----
> > From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Wednesday, November 18, 2015 11:54 AM
> > To: Gore, Tim
> > Cc: intel-gfx@lists.freedesktop.org; mika.kuoppala@linux.com; Wood,
> > Thomas
> > Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/gem_reset_stats.c: prepare for
> > per engine resets
> > 
> > On Wed, Nov 18, 2015 at 10:24:43AM +0000, tim.gore@intel.com wrote:
> > > From: Tim Gore <tim.gore@intel.com>
> > >
> > > when checking to make sure that the driver has performed the expected
> > > number of resets, this test looks at the reset_count, which is
> > > incremented each time the GPU is reset. Upcoming changes in the way
> > > GPU hangs are handled mean that in most cases (and in all the cases in
> > > this
> > > test) only a single GPU engine is reset which does not cause the
> > > reset_count to be incremented. This is already causing this test to
> > > fail on Android. In this case we can instead look at the batch_active
> > > count which is also returned from the i915_get_reset_stats_ioctl and
> > > is incremented by both a single engine reset and a full gpu reset.
> > > There are differences between the reset_count and the batch_active
> > > count, but for establishing that the correct number of resets have
> > > occured either can be used.
> > > This change enables this test to run successfully on Android and will
> > > mean that the test does not break when the TDR patches get merged into
> > > the uptream driver.
> > >
> > > Signed-off-by: Tim Gore <tim.gore@intel.com>
> > 
> > Why doesn't TDR just count resets correctly?
> > -Daniel
> > 
> It does. It just doesn't do gpu resets for most hangs. Instead it resets
> as single command streamer which is much less intrusive and loses the
> minimum amount of work.

Again: Why does TDR not count engine resets as resets? Afaiui that seems
to be the problem you're working around here.
-Daniel

>   Tim
> 
> > > ---
> > >  tests/gem_reset_stats.c | 41
> > > ++++++++++++++++++++++++++---------------
> > >  1 file changed, 26 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/tests/gem_reset_stats.c b/tests/gem_reset_stats.c index
> > > 4cbbb4e..5ec026f 100644
> > > --- a/tests/gem_reset_stats.c
> > > +++ b/tests/gem_reset_stats.c
> > > @@ -104,9 +104,9 @@ static int gem_reset_stats(int fd, int ctx_id,
> > >
> > >  	rs->ctx_id = ctx_id;
> > >  	rs->flags = 0;
> > > -	rs->reset_count = rand();
> > > -	rs->batch_active = rand();
> > > -	rs->batch_pending = rand();
> > > +	rs->reset_count = UINT32_MAX;
> > > +	rs->batch_active = UINT32_MAX;
> > > +	rs->batch_pending = UINT32_MAX;
> > >  	rs->pad = 0;
> > >
> > >  	do {
> > > @@ -690,6 +690,18 @@ static int get_reset_count(int fd, int ctx)
> > >  	return rs.reset_count;
> > >  }
> > >
> > > +static int get_active_count(int fd, int ctx) {
> > > +	int ret;
> > > +	struct local_drm_i915_reset_stats rs;
> > > +
> > > +	ret = gem_reset_stats(fd, ctx, &rs);
> > > +	if (ret)
> > > +		return ret;
> > > +
> > > +	return rs.batch_active;
> > > +}
> > > +
> > >  static void test_close_pending_ctx(void)  {
> > >  	int fd, h;
> > > @@ -837,17 +849,16 @@ static void test_reset_count(const bool
> > > create_ctx)
> > >
> > >  	assert_reset_status(fd, ctx, RS_NO_ERROR);
> > >
> > > -	c1 = get_reset_count(fd, ctx);
> > > -	igt_assert(c1 >= 0);
> > > +	c1 = get_active_count(fd, ctx);
> > > +	igt_assert(c1 == 0);
> > >
> > >  	h = inject_hang(fd, ctx);
> > >  	igt_assert_lte(0, h);
> > >  	gem_sync(fd, h);
> > >
> > >  	assert_reset_status(fd, ctx, RS_BATCH_ACTIVE);
> > > -	c2 = get_reset_count(fd, ctx);
> > > -	igt_assert(c2 >= 0);
> > > -	igt_assert(c2 == (c1 + 1));
> > > +	c2 = get_active_count(fd, ctx);
> > > +	igt_assert(c2 == 1);
> > >
> > >  	igt_fork(child, 1) {
> > >  		igt_drop_root();
> > > @@ -877,9 +888,9 @@ static int _test_params(int fd, int ctx, uint32_t
> > > flags, uint32_t pad)
> > >
> > >  	rs.ctx_id = ctx;
> > >  	rs.flags = flags;
> > > -	rs.reset_count = rand();
> > > -	rs.batch_active = rand();
> > > -	rs.batch_pending = rand();
> > > +	rs.reset_count = UINT32_MAX;
> > > +	rs.batch_active = UINT32_MAX;
> > > +	rs.batch_pending = UINT32_MAX;
> > >  	rs.pad = pad;
> > >
> > >  	do {
> > > @@ -976,14 +987,14 @@ static void defer_hangcheck(int ring_num)
> > >
> > >  	igt_skip_on(next_ring == current_ring);
> > >
> > > -	count_start = get_reset_count(fd, 0);
> > > -	igt_assert_lte(0, count_start);
> > > +	count_start = get_active_count(fd, 0);
> > > +	igt_assert(count_start == 0);
> > >
> > >  	igt_assert(inject_hang_ring(fd, 0, current_ring->exec, true));
> > >  	while (--seconds) {
> > >  		igt_assert(exec_valid_ring(fd, 0, next_ring->exec));
> > >
> > > -		count_end = get_reset_count(fd, 0);
> > > +		count_end = get_active_count(fd, 0);
> > >  		igt_assert_lte(0, count_end);
> > >
> > >  		if (count_end > count_start)
> > > @@ -992,7 +1003,7 @@ static void defer_hangcheck(int ring_num)
> > >  		sleep(1);
> > >  	}
> > >
> > > -	igt_assert_lt(count_start, count_end);
> > > +	igt_assert(count_end == 1);
> > >
> > >  	close(fd);
> > >  }
> > > --
> > > 1.9.1
> > >
> > > _______________________________________________
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-11-18 14:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-18 10:24 [PATCH i-g-t] tests/gem_reset_stats.c: prepare for per engine resets tim.gore
2015-11-18 11:54 ` Daniel Vetter
2015-11-18 12:15   ` Gore, Tim
2015-11-18 14:12     ` Daniel Vetter [this message]
2015-11-18 14:46       ` Gore, Tim

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=20151118141205.GT20799@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mika.kuoppala@linux.com \
    --cc=thomas.wood@intel.com \
    --cc=tim.gore@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.