A purely recursive batch has the downside that it is a severe drain on system resources (see commit f978cc027cd0 "lib/dummyload: Pad with a few nops so that we do not completely hog the system") which can result in the test being starved and failing to make reasonably progress. For more reliable resets, also include an arbitration point. This should lessen the efficacy of the hang... Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> Cc: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx> --- lib/igt_gt.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/lib/igt_gt.c b/lib/igt_gt.c index 89727d22..2aebad14 100644 --- a/lib/igt_gt.c +++ b/lib/igt_gt.c @@ -313,12 +313,12 @@ igt_hang_t igt_hang_ctx(int fd, len = 2; if (intel_gen(intel_get_drm_devid(fd)) >= 8) len++; - b[0] = MI_BATCH_BUFFER_START | (len - 2); - b[len] = MI_BATCH_BUFFER_END; - b[len+1] = MI_NOOP; - gem_write(fd, exec.handle, 0, b, sizeof(b)); + b[0] = 0x5 << 24; /* ARB_CHk */ + b[1] = MI_BATCH_BUFFER_START | (len - 2); + b[len+1] = MI_BATCH_BUFFER_END; + gem_write(fd, exec.handle, 4096-sizeof(b), b, sizeof(b)); - reloc.offset = sizeof(uint32_t); + reloc.offset = 4096 - sizeof(b) + 2*sizeof(uint32_t); reloc.target_handle = exec.handle; reloc.read_domains = I915_GEM_DOMAIN_COMMAND; -- 2.15.0.rc2 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
