On Wed, 07 Dec 2016, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > Do the module reload test first, so that it has the best chance of > succeeding without outside influence (broken driver). And then do it > last, so that it has the best chance of catching some missing > finalisation (e.g. memleak) over the lifetime of the testing. I see your point, and maybe I worry too much, but running stuff with a reloaded module is never the normal use case. This makes all the test run with a reloaded module. BR, Jani. > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Cc: Petri Latvala <petri.latvala@xxxxxxxxx> > --- > tests/intel-ci/fast-feedback.testlist | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/tests/intel-ci/fast-feedback.testlist b/tests/intel-ci/fast-feedback.testlist > index e25facf3..b79b0c14 100644 > --- a/tests/intel-ci/fast-feedback.testlist > +++ b/tests/intel-ci/fast-feedback.testlist > @@ -1,11 +1,10 @@ > +igt@drv_module_reload@basic-reload > +igt@drv_module_reload@basic-reload-inject > igt@core_auth@basic-auth > igt@core_prop_blob@basic > igt@drv_getparams_basic@basic-eu-total > igt@drv_getparams_basic@basic-subslice-total > igt@drv_hangman@error-state-basic > -igt@drv_module_reload@basic-reload > -igt@drv_module_reload@basic-reload-inject > -igt@drv_module_reload@basic-reload-final > igt@gem_basic@bad-close > igt@gem_basic@create-close > igt@gem_basic@create-fd-close > @@ -245,3 +244,4 @@ igt@vgem_basic@mmap > igt@vgem_basic@second-client > igt@vgem_basic@sysfs > igt@vgem_basic@unload > +igt@drv_module_reload@basic-reload-final # keep last -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
