From: Daniel Vetter <daniel@ffwll.ch>
To: tim.gore@intel.com
Cc: mika.kuoppala@linux.com, intel-gfx@lists.freedesktop.org,
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 12:54:13 +0100 [thread overview]
Message-ID: <20151118115413.GR20799@phenom.ffwll.local> (raw)
In-Reply-To: <1447842283-4226-1-git-send-email-tim.gore@intel.com>
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
> ---
> 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-11-18 11:54 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 [this message]
2015-11-18 12:15 ` Gore, Tim
2015-11-18 14:12 ` Daniel Vetter
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=20151118115413.GR20799@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.