Re: [igt-dev] [PATCH i-g-t 2/3] tests/gem_eio: Speed up test execution

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Quoting Antonio Argenziano (2018-03-22 17:32:46)
> 
> 
> On 22/03/18 05:42, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-03-22 12:36:58)
> >>
> >> On 22/03/2018 11:39, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2018-03-22 11:17:11)
> >>>
> >>>>           trigger_reset(fd);
> >>>> +
> >>>> +       /* HACK for CI */
> >>>> +       igt_assert(igt_nsec_elapsed(&ts) < 5e9);
> >>>
> >>> igt_seconds_elapsed() the approximation is worth the readability.
> >>>
> >>> In this case you might like to try igt_set_timeout(), as I think each
> >>> subtest and exithandlers are in place to make them robust against
> >>> premature failures.
> >>
> >> Well this was just to see that will happen on the shards here. As
> >> mentioned in the commit I get that yet unexplained GPU hang at subtest
> >> exit here. So the assert above is just to notice if the same happens on
> >> shards.
> > 
> > And I was thinking it was a reasonable enhancement :) Probably more so
> > for igt/gem_wait itself to ask that if we reset the request we are
> > waiting upon it completes in a timely manner. (We don't care about
> > wedged handling there, just reset handling.)
> 
> How about checking for reset when we do gem_test_engine(), which seems 
> to not fail on reset, (crudely https://paste.debian.net/1016059/)?

I was thinking that the timeout would be good around the test as a
whole, because it is now meant to be uberfast.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux