How about a patch 0 to enable hang testing contexts on all rings now?
Then exploration of how one ring affects another...
You will want to use busy batches to load the engines without hanging,
that will be tricky...
On Thu, Dec 01, 2016 at 03:31:43PM +0200, Mika Kuoppala wrote:
> Now that we replay the non guilty contexts and always replay
> the default ctx, even when guilty, the assumptions of how many
> active and pending batches there was in the time of reset has
> changed.
>
> Driver doesn't increment pending counts for contexts that it
> considered unaffected by reset. Because it can now replay the
> queued requests.
>
> For contexts, guilty of reset, we replay the request envelopes,
> but nop the batchbuffer starts. This changes of how many 'hangs'
> we think there were queued. As future queued hangs are now NOPed
> out, we need to change the assumption of active counts also.
>
> Adapt to these changes of how the replaying of batches affect
> the assertions in pending/active counting and banning tests.
> While doing this, throw out the retrying to be more strict about
> the determinism we want to achieve.
>
> Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> Signed-off-by: Mika Kuoppala <mika.kuoppala@xxxxxxxxx>
> ---
> tests/gem_reset_stats.c | 154 ++++++++++++++++++------------------------------
> 1 file changed, 56 insertions(+), 98 deletions(-)
>
> diff --git a/tests/gem_reset_stats.c b/tests/gem_reset_stats.c
> index 3de74af..2718a33 100644
> --- a/tests/gem_reset_stats.c
> +++ b/tests/gem_reset_stats.c
> @@ -152,7 +152,7 @@ static struct timespec ts_injected;
>
> #define BAN HANG_ALLOW_BAN
> #define ASYNC 2
> -static void inject_hang(int fd, uint32_t ctx,
> +static bool inject_hang(int fd, uint32_t ctx,
> const struct intel_execution_engine *e,
> unsigned flags)
> {
> @@ -163,6 +163,8 @@ static void inject_hang(int fd, uint32_t ctx,
> hang = igt_hang_ctx(fd, ctx, e->exec_id | e->flags, flags & BAN, NULL);
> if ((flags & ASYNC) == 0)
> igt_post_hang_ring(fd, hang);
> +
> + return hang.handle >= 0;
Never returns false. Future patch?
> static const char *status_to_string(int x)
> @@ -239,7 +241,7 @@ static void test_rs(const struct intel_execution_engine *e,
> if (i == hang_index)
> assert_reset_status(i, fd[i], 0, RS_BATCH_ACTIVE);
> if (i > hang_index)
> - assert_reset_status(i, fd[i], 0, RS_BATCH_PENDING);
> + assert_reset_status(i, fd[i], 0, RS_NO_ERROR);
> }
>
> igt_assert(igt_seconds_elapsed(&ts_injected) <= 30);
> @@ -312,10 +314,10 @@ static void test_rs_ctx(const struct intel_execution_engine *e,
> RS_BATCH_ACTIVE);
> if (i == hang_index && j > hang_context)
> assert_reset_status(i, fd[i], ctx[i][j],
> - RS_BATCH_PENDING);
> + RS_NO_ERROR);
> if (i > hang_index)
> assert_reset_status(i, fd[i], ctx[i][j],
> - RS_BATCH_PENDING);
> + RS_NO_ERROR);
> }
> }
>
> @@ -325,128 +327,84 @@ static void test_rs_ctx(const struct intel_execution_engine *e,
> }
> }
>
> -static void test_ban(const struct intel_execution_engine *e)
> +static void test_ban_ctx(const struct intel_execution_engine *e,
> + const bool ban_default)
> {
> struct local_drm_i915_reset_stats rs_bad, rs_good;
> - int fd_bad, fd_good;
> - int ban, retry = 10;
> + int fd_bad, fd_good, i;
> + uint32_t ctx_good, ctx_bad;
> int active_count = 0, pending_count = 0;
>
> fd_bad = drm_open_driver(DRIVER_INTEL);
> fd_good = drm_open_driver(DRIVER_INTEL);
>
> - assert_reset_status(fd_bad, fd_bad, 0, RS_NO_ERROR);
> + ctx_good = gem_context_create(fd_bad);
> + if (!ban_default)
> + ctx_bad = gem_context_create(fd_bad);
> + else
> + ctx_bad = 0;
> +
> + assert_reset_status(fd_bad, fd_bad, ctx_bad, RS_NO_ERROR);
> + assert_reset_status(fd_bad, fd_bad, ctx_good, RS_NO_ERROR);
> assert_reset_status(fd_good, fd_good, 0, RS_NO_ERROR);
>
> - noop(fd_bad, 0, e);
> - noop(fd_good, 0, e);
> + igt_assert_lt(0, noop(fd_bad, ctx_bad, e));
> + igt_assert_lt(0, noop(fd_bad, ctx_good, e));
> + igt_assert_lt(0, noop(fd_good, 0, e));
Yuck.
__noop();
noop() { igt_assert_eq(__noop, 0));
(Or better names than noop? )
Otherwise, lgtm. R-b if you feel so inclined.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
