[Intel-gfx] [PATCH igt 1/5] igt/gem_eio: inflight wedged requires long plugging
Petri Latvala
petri.latvala at intel.com
Mon Sep 11 10:57:08 UTC 2017
On Mon, Sep 11, 2017 at 09:55:58AM +0100, Chris Wilson wrote:
> As our hangcheck may exceed 10s to declare the device wedged, we need to
> hold the plugging fence indefinitely. This makes using vgem as our input
> fence unusable, so resort to using sw_sync. At the same time, we can
> then check that the async result is also -EIO.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102616
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> ---
> tests/gem_eio.c | 79 ++++++++++++++++++++++-----------------------------------
> 1 file changed, 31 insertions(+), 48 deletions(-)
>
> diff --git a/tests/gem_eio.c b/tests/gem_eio.c
> index 15120842..249510e7 100644
> --- a/tests/gem_eio.c
> +++ b/tests/gem_eio.c
> @@ -39,7 +39,7 @@
>
> #include <drm.h>
>
> -#include "igt_vgem.h"
> +#include "sw_sync.h"
>
> IGT_TEST_DESCRIPTION("Test that specific ioctls report a wedged GPU (EIO).");
>
> @@ -158,66 +158,49 @@ static void test_wait(int fd)
> trigger_reset(fd);
> }
>
> -struct cork {
> - int device;
> - uint32_t handle;
> - uint32_t fence;
> -};
> -
> -static void plug(int fd, struct cork *c)
> -{
> - struct vgem_bo bo;
> - int dmabuf;
> -
> - c->device = __drm_open_driver(DRIVER_VGEM);
> - igt_require(c->device != -1);
> -
> - bo.width = bo.height = 1;
> - bo.bpp = 4;
> - vgem_create(c->device, &bo);
> - c->fence = vgem_fence_attach(c->device, &bo, VGEM_FENCE_WRITE);
> -
> - dmabuf = prime_handle_to_fd(c->device, bo.handle);
> - c->handle = prime_fd_to_handle(fd, dmabuf);
> - close(dmabuf);
> -}
> -
> -static void unplug(struct cork *c)
> -{
> - vgem_fence_signal(c->device, c->fence);
> - close(c->device);
> -}
> -
> -static void test_inflight(int fd)
> +static void test_inflight_external(int fd)
> {
> struct drm_i915_gem_execbuffer2 execbuf;
> - struct drm_i915_gem_exec_object2 obj[2];
> + struct drm_i915_gem_exec_object2 obj;
> uint32_t bbe = MI_BATCH_BUFFER_END;
> igt_hang_t hang;
> - struct cork cork;
> + int timeline, fence;
> +
> + igt_require_sw_sync();
> + igt_require(gem_has_exec_fence(fd));
> +
> + timeline = sw_sync_timeline_create();
> + fence = sw_sync_timeline_create_fence(timeline, 1);
>
> igt_require(i915_reset_control(false));
> hang = igt_hang_ring(fd, I915_EXEC_DEFAULT);
>
> - plug(fd, &cork);
> -
> - memset(obj, 0, sizeof(obj));
> - obj[0].handle = cork.handle;
> - obj[1].handle = gem_create(fd, 4096);
> - gem_write(fd, obj[1].handle, 0, &bbe, sizeof(bbe));
> + memset(&obj, 0, sizeof(obj));
> + obj.handle = gem_create(fd, 4096);
> + gem_write(fd, obj.handle, 0, &bbe, sizeof(bbe));
>
> memset(&execbuf, 0, sizeof(execbuf));
> - execbuf.buffers_ptr = to_user_pointer(obj);
> - execbuf.buffer_count = 2;
> + execbuf.buffers_ptr = to_user_pointer(&obj);
> + execbuf.buffer_count = 1;
> + execbuf.flags = I915_EXEC_FENCE_IN | I915_EXEC_FENCE_OUT;
> + execbuf.rsvd2 = (uint32_t)fence;
>
> - gem_execbuf(fd, &execbuf);
> + gem_execbuf_wr(fd, &execbuf);
> + close(fence);
>
> - igt_post_hang_ring(fd, hang);
> - unplug(&cork); /* only now submit our batches */
> - igt_assert_eq(__gem_wait(fd, obj[1].handle, -1), 0);
> + fence = execbuf.rsvd2 >> 32;
> + igt_assert(fence != -1);
> +
> + igt_post_hang_ring(fd, hang); /* wedged, with an unready batch */
> + sw_sync_timeline_inc(timeline, 1); /* only now submit our batches */
> +
> + igt_assert_eq(__gem_wait(fd, obj.handle, -1), 0);
> + igt_assert_eq(sync_fence_status(fence), -EIO);
> + close(fence);
>
> igt_require(i915_reset_control(true));
> trigger_reset(fd);
> + close(timeline);
> }
>
> igt_main
> @@ -241,8 +224,8 @@ igt_main
> igt_subtest("wait")
> test_wait(fd);
>
> - igt_subtest("in-flight")
> - test_inflight(fd);
> + igt_subtest("in-flight-external")
> + test_inflight_external(fd);
>
gem_eio at in-flight is currently filtered in cibuglog. Martin, are you
prepared for this subtest rename?
--
Petri Latvala
More information about the Intel-gfx
mailing list