Historically, we've had many problems with missed interrupt/seqno syndrome and so have focus on testing with gem_sync. However, these tests rely on the kernel itself reporting the issue which it no longer does. So why the extra variety may impose different timing of execution on the HW (and so different interrupt timings which may or may not help uncover issues), they do not have any variety in driver coverage. Reduce the variety (halving the associated runtime) as they are no more likely to spot an issue than multiple runs through BAT.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> --- tests/intel-ci/fast-feedback.testlist | 3 --- 1 file changed, 3 deletions(-) diff --git a/tests/intel-ci/fast-feedback.testlist b/tests/intel-ci/fast-feedback.testlist index f697eb0cf..8c574d910 100644 --- a/tests/intel-ci/fast-feedback.testlist +++ b/tests/intel-ci/fast-feedback.testlist @@ -45,9 +45,6 @@ igt@gem_ringfill@basic-default-forked igt@gem_ringfill@basic-default-fd igt@gem_sync@basic-all igt@gem_sync@basic-each -igt@gem_sync@basic-many-each -igt@gem_sync@basic-store-all -igt@gem_sync@basic-store-each igt@gem_tiled_blits@basic igt@gem_tiled_fence_blits@basic igt@gem_tiled_pread_basic -- 2.25.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
