Quoting Tvrtko Ursulin (2018-03-01 09:21:52) > > On 01/03/2018 08:08, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-02-28 17:15:19) > >> From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > >> > >> Verify that the reported busyness is in line with what would we expect > >> from a batch which causes a hang and gets kicked out from the engine. > >> > >> v2: Change to explicit igt_force_gpu_reset instead of guessing when a spin > >> batch will hang. (Chris Wilson) > >> > >> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > > > > It's nice and quick, yes. However, sometime the opposite is true and you > > have to wait for the batch you want to start before pulling the trigger. > > > > I'd put a usleep(100) in there /* Wait for batch to execute */ and we > > Hm, but reset is triggered after the first sleep (which checks for 100% > busy). So even the non-hanging test flavour could be affect if the delay > before execution is so long. So by this logic this usleep(100) (or more > for small core CI) should then go to many tests. Only difference in the > hang flavour is that if it completely failed to run until after the > reset, then the idle assert would fail. So maybe I should just add an > assert that the batch is idle before sampling pmu after reset? Sneaky. Yes, that will work, just add a comment for the case where it may fail (reset before batch execution). -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
