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
