[Intel-gfx] [PATCH i-g-t] tests/gem_eio: Nerf in-flight-suspend

[Daniel Vetter]

On Mon, Oct 30, 2017 at 12:15:05PM +0200, Petri Latvala wrote:
> Use TEST_NONE instead of TEST_DEVICES to prevent a machine death that
> happens on a particular model of SNB (2600 is affected, 2520m is
> not). Reset is unreliable, but the exact setup to trigger the death
> and how to work around it are not found at this time.
> 
> References: https://intel-gfx-ci.01.org/tree/drm-tip/igt@gem_eio@in-flight-suspend.html
> References: https://bugs.freedesktop.org/show_bug.cgi?id=103289
> Suggested-by: Chris Wilson <chris at chris-wilson.co.uk>
> Signed-off-by: Petri Latvala <petri.latvala at intel.com>
> CC: Daniel Vetter <daniel.vetter at ffwll.ch>
> CC: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> CC: "Lofstedt, Marta" <marta.lofstedt at intel.com>
> CC: Martin Peres <martin.peres at linux.intel.com>
> ---
> 
> Tested on my SNB and the machine survived the test.
> 
> tests/gem_eio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/gem_eio.c b/tests/gem_eio.c
> index 2d4c95f4..ca0020f1 100644
> --- a/tests/gem_eio.c
> +++ b/tests/gem_eio.c
> @@ -238,7 +238,7 @@ static void test_inflight_suspend(int fd)
>  	}
>  
>  	igt_system_suspend_autoresume(SUSPEND_STATE_MEM,
> -				      SUSPEND_TEST_DEVICES);
> +				      SUSPEND_TEST_NONE);

#define SUSPEND_TEST_NORMAL SUSPEND_TEST_NONE

... might help in clarifying this a bit.

And I guess we need to update the commit message to state that we just
paper over the race (sw or hw, who knows) that seems to be there with a
full s/r cycle. Which has the benefit of still exercising these codepaths,
so much better from a coverage pov than blacklisting.

With the commit message fixed (the new #define should be a separate patch
imo):

Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>

>  
>  	igt_post_hang_ring(fd, hang);
>  
> -- 
> 2.14.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch