Quoting Mika Kuoppala (2019-06-26 14:11:49) > Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > > > In order for the reset count to be accurate across our selftest, we need > > to prevent the background retire worker from modifying our expected > > state. > > > > Ok, to summarize the irc discussion we had: The above holds true > for igt_reset_engine_nop only. As there is no race in > global reset path...currently. > > But there is intent towards symmetry on both paths > so it makes sense to keep the tests aligned. > > The commit msg could be enhanced on this regard. > > Also while looking through this, we do increase > the reset_count rather early before the failpaths. > even with the resets disabled it gets incremented. > So now it is more of a attempted reset count. We don't expect it to fail, and if it does we wedge and report -EIO not just a boring -EINVAL (or in theory we do -- that's generally the approach we take elsewhere, treating the GPU going south as a more severe failure than the test itself failing to fulfil its contract). -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
