[PATCH igt] intel-ci: Do module loads first + last

[PATCH igt] intel-ci: Do module loads first + last

[Chris Wilson]

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.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Petri Latvala <petri.latvala@intel.com>
---
 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
-- 
2.11.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH igt] intel-ci: Do module loads first + last

[Jani Nikula]

On Wed, 07 Dec 2016, Chris Wilson <chris@chris-wilson.co.uk> 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@chris-wilson.co.uk>
> Cc: Petri Latvala <petri.latvala@intel.com>
> ---
>  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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH igt] intel-ci: Do module loads first + last

[Chris Wilson]

On Wed, Dec 07, 2016 at 09:41:42PM +0200, Jani Nikula wrote:
> On Wed, 07 Dec 2016, Chris Wilson <chris@chris-wilson.co.uk> 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.

You can move the reload-inject to the end, but something I would like
for CI to start doing is not allowing i915 to load during the boot. We
miss error messages from that first load that do not appear again later.
:(

That again is an unusual configuration (so we still need
initramfs/builtin checking). Combitorial explosions of combitorial
explosions.

Anyway reload-final really should be the final operation irrespective of
this discussion :)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH igt] intel-ci: Do module loads first + last

[Petri Latvala]

> On Wed, Dec 07, 2016 at 09:41:42PM +0200, Jani Nikula wrote:
> > 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.

Currently, the reload tests are in positions 6-8 due to alphabetical
ordering. Only

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

are run before drv_module_reload@*


On Wed, Dec 07, 2016 at 08:09:07PM +0000, Chris Wilson wrote:
> You can move the reload-inject to the end, but something I would
> like for CI to start doing is not allowing i915 to load during the
> boot. We miss error messages from that first load that do not appear
> again later.  :(
> 
> That again is an unusual configuration (so we still need
> initramfs/builtin checking). Combitorial explosions of combitorial
> explosions.

Yeah, several unusual configurations for several values of "unusual"
exist, and it would be nice to have them tested. Given the choice of
configurations to test in CI, I would prefer the usual one first, and
unusual ones as much as resources allow.

That given:

> Anyway reload-final really should be the final operation irrespective of
> this discussion :)

We should move all drv_module_reload@* tests to the bottom
really. That would make the other tests run in a usual configuration,
and as a nice side-effect, with the admin-specified global module
parameters (kernel cmdline, module config in /etc...). Those are
currently ignored because of the reload (oopsie).

Chris, Jani, comments on moving all reloads to the bottom?


--
Petri Latvala
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH igt] intel-ci: Do module loads first + last

[Chris Wilson]

On Fri, Dec 09, 2016 at 12:04:58PM +0200, Petri Latvala wrote:
> We should move all drv_module_reload@* tests to the bottom
> really. That would make the other tests run in a usual configuration,
> and as a nice side-effect, with the admin-specified global module
> parameters (kernel cmdline, module config in /etc...). Those are
> currently ignored because of the reload (oopsie).

Hmm. (That may not be a good thing depending on your pov ;) But libkmod
should be providing those defaults and settings as well.
 
> Chris, Jani, comments on moving all reloads to the bottom?

We should only need the reload and fault-injection. Just check the test
that it always leave the system in the same state it found it in.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx