Some overlap with gem_exec_fence, but confirm that light for waiting on
a fence (both native and external), that a request queued is also
flagged as EIO upon wedging.
Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
---
tests/gem_eio.c | 41 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)
diff --git a/tests/gem_eio.c b/tests/gem_eio.c
index 7aa4af8f..8b9bec90 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -159,6 +159,44 @@ static void test_wait(int fd)
trigger_reset(fd);
}
+static void test_inflight(int fd)
+{
+ struct drm_i915_gem_execbuffer2 execbuf;
+ struct drm_i915_gem_exec_object2 obj[2];
+ uint32_t bbe = MI_BATCH_BUFFER_END;
+ igt_hang_t hang;
+ int fence;
+
+ igt_require(gem_has_exec_fence(fd));
+
+ igt_require(i915_reset_control(false));
+ hang = igt_hang_ring(fd, I915_EXEC_DEFAULT);
+
+ memset(obj, 0, sizeof(obj));
+ obj[0].handle = hang.handle;
+ obj[0].flags = EXEC_OBJECT_WRITE;
+ obj[1].handle = gem_create(fd, 4096);
+ gem_write(fd, obj[1].handle, 0, &bbe, sizeof(bbe));
+
+ memset(&execbuf, 0, sizeof(execbuf));
+ execbuf.buffers_ptr = to_user_pointer(obj);
+ execbuf.buffer_count = 2;
+ execbuf.flags = I915_EXEC_DEFAULT | I915_EXEC_FENCE_OUT;
+
+ gem_execbuf_wr(fd, &execbuf);
+ fence = execbuf.rsvd2 >> 32;
+ igt_assert(fence != -1);
+
+ igt_post_hang_ring(fd, hang);
+
+ igt_assert_eq(__gem_wait(fd, obj[1].handle, -1), 0);
+ igt_assert_eq(sync_fence_status(fence), -EIO);
+ close(fence);
+
+ igt_assert(i915_reset_control(true));
+ trigger_reset(fd);
+}
+
static void test_inflight_external(int fd)
{
struct drm_i915_gem_execbuffer2 execbuf;
@@ -319,6 +357,9 @@ igt_main
igt_subtest("wait")
test_wait(fd);
+ igt_subtest("in-flight")
+ test_inflight(fd);
+
igt_subtest("in-flight-external")
test_inflight_external(fd);
--
2.14.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
