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

[Martin Peres]

On 19/10/17 12:51, Daniel Vetter wrote:
> CI gets upset about it resulting in an incomplete, let's skip it until
> that's fixed to avoid havoc in the CI farm. Of course this should/will
> be reverted as soon as we have a fix (similar to how we dealt with the
> snb-dies-in-blt-hangs issue).
> 
> Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> Cc: Chris Wilson <chris at chris-wilson.co.uk>
> Cc: "Lofstedt, Marta" <marta.lofstedt at intel.com>
> Cc: Martin Peres <martin.peres at linux.intel.com>
> 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
> Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> ---
>   tests/gem_eio.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/tests/gem_eio.c b/tests/gem_eio.c
> index 899cb62728e3..28375e208232 100644
> --- a/tests/gem_eio.c
> +++ b/tests/gem_eio.c
> @@ -218,6 +218,9 @@ static void test_inflight_suspend(int fd)
>   	igt_require(gem_has_exec_fence(fd));
>   	igt_require(i915_reset_control(false));
>   
> +	igt_skip_on_f(IS_SANDYBRIDGE(intel_get_drm_devid(fd)),
> +		      "random incompletes in CI with this test\n");
> +

So, let's recap the problem here:
  - Any incomplete in sharded runs mean that the platform is unfit for 
pre-merge (because any other test after will go from pass to notrun)
  - We can't fix issues immediately, especially for old platforms

This patch is sweeping the test under the rug by using the skip output, 
which is not only hard to track, it is also misleading.

After discussing with Marta, Arek and Petri, we found some consensus on 
the following proposal (terminology is up for debate):

- Introduce igt_dodge_on(cond, label): Report a pre-emptive 'fail' when 
the condition is true. Make sure this is over-ridable with IGT_DODGE=0 
so as we can easily run these tests without recompiling them.

- Introduce a new piglit result (dodged), so as we can more easily keep 
track of the issue (no need to open the piglit results).

Any thoughts?

>   	memset(obj, 0, sizeof(obj));
>   	obj[0].flags = EXEC_OBJECT_WRITE;
>   	obj[1].handle = gem_create(fd, 4096);
>