Re: [PATCH igt 1/5] igt/gem_eio: inflight wedged requires long plugging

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxx>
> ---
>  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@in-flight is currently filtered in cibuglog. Martin, are you
prepared for this subtest rename?


-- 
Petri Latvala
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux