On 07/17/2018 03:52 PM, Chris Wilson wrote:
The CI infrastructure is ready and is already running the kernel
selftests in BAT, so there is no reason to blacklist them from the
shards.
Signed-off-by: Chris Wilson <[email protected]>
Cc: Tomi Sarvela <[email protected]>
Cc: Petri Latvala <[email protected]>
Cc: Martin Peres <[email protected]>
---
tests/intel-ci/blacklist.txt | 2 --
1 file changed, 2 deletions(-)
diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt
index d65d8ff35..7faec8b5c 100644
--- a/tests/intel-ci/blacklist.txt
+++ b/tests/intel-ci/blacklist.txt
@@ -2,8 +2,6 @@ igt@meta_test(@.*)?
###############################################
# GEM
###############################################
-igt@drv_selftest(@.*)?
-igt@drm_mm(@.*)?
igt@gem_busy@.*hang.*
igt@gem_close_race@(?!.*basic).*
igt@gem_concurrent_blit(@.*)?
From Intel-GFX-CI point of view:
Because of the test order randomization, this blacklist is used by IGT
builder when creating the randomized testlists for shard nodes, and
builder might or might not have knowledge of i915 or selftests.
The selftests are scraped to their own testlist in kernel build time (as
they are kernel specific) and used separately after fast-feedback or as
a last shard in a full run.
I'd advise not to whitelist drv_selftests or drm_mm. If the selftest
coverage is considered full replacement for gem_exec_flush tests, then
remove blacklisting of igt@gem_exec_flush@(?!.*basic).* from
blacklist.txt and remove same tests from fast-feedback.testlist.
Regards,
Tomi
--
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
