[Intel-gfx] [PATCH i-g-t 1/2] intel-ci: Unblacklist selftests
Chris Wilson
chris at chris-wilson.co.uk
Tue Jul 17 13:19:23 UTC 2018
Quoting Tomi Sarvela (2018-07-17 14:12:27)
> 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 <chris at chris-wilson.co.uk>
> > Cc: Tomi Sarvela <tomi.p.sarvela at intel.com>
> > Cc: Petri Latvala <petri.latvala at intel.com>
> > Cc: Martin Peres <martin.peres at linux.intel.com>
> > ---
> > 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 at meta_test(@.*)?
> > ###############################################
> > # GEM
> > ###############################################
> > -igt at drv_selftest(@.*)?
> > -igt at drm_mm(@.*)?
> > igt at gem_busy@.*hang.*
> > igt at gem_close_race@(?!.*basic).*
> > igt at 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 at gem_exec_flush@(?!.*basic).* from
> blacklist.txt and remove same tests from fast-feedback.testlist.
Nah, here I was just going "why blacklist these perfectly fine tests?
The discrimination has to end!" I just wanted to be sure we were running
them everywhere.
-Chris
More information about the Intel-gfx
mailing list