They do run separately. It's just that when one fails it does not close the fd and the next cannot open it as master. Is there a mechanism for closing the fd (or any other tidy up on close.failure). As the test runner implements a psudo exception handler it should really have a "final"/"skip" handler so that the tidyup can be done cleanly. That was the question that was asked and not answered. Peter. -----Original Message----- From: Daniel Vetter [mailto:daniel.vetter@xxxxxxxx] On Behalf Of Daniel Vetter Sent: Tuesday, August 2, 2016 3:37 PM To: Antoine, Peter <peter.antoine@xxxxxxxxx> Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>; intel-gfx@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [I-G-T 3/3] igt/gem_mocs_settings: Reduce the amount of cascading failures On Mon, Aug 01, 2016 at 10:33:17AM +0100, Peter Antoine wrote: > On Mon, 1 Aug 2016, Chris Wilson wrote: > > > On Fri, Jul 29, 2016 at 10:34:36AM +0100, Peter Antoine wrote: > > > If one of the previous tests fails then the following tests fail. > > > This patch means that the following tests do not fail when the > > > previous test fails (for some cases). > > > > The problem is just gem_mocs_settings hasn't split its tests up into > > subtests. > Chris, > > Can you expand? The tests are at the minimal size for sensible results > (I think). The problem is opening the driver for master when the test > fails then the following tests will fail as master is not closed. > > Is there a mechanism in the igt framework for doing this close on > failure/skip? > > If I move the master open code in the fixtures will this get called on > all exit cases? For a real test runner you need to run each individual subtest separate (to avoid contamination). Then process exit will take care of any cleanup needed with file descriptors. For anything else there's exit handlers, but they're not 100% reliable Adding hacks to make subtest runs differently isn't really how igt tests are meant to be. Hence I concure on Chris' objection here. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
