Quoting Mika Kuoppala (2019-09-24 13:44:54) > Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > > > Beware the slithy t'oves. > > > > Forked GTT access on icl is notoriously slow, so rather than spend an > > eternity checking the whole object, check for a completion event after > > handling the pagefault. It's is the race of the pagefault vs reset that > > we care most about, and we expect the bug to result in the pagefault > > being blocked indefinitely, so checking afterwards does not reduce > > coverage. > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx> > > --- > > tests/i915/gem_mmap_gtt.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/tests/i915/gem_mmap_gtt.c b/tests/i915/gem_mmap_gtt.c > > index 0428a1372..91da5a37b 100644 > > --- a/tests/i915/gem_mmap_gtt.c > > +++ b/tests/i915/gem_mmap_gtt.c > > @@ -602,6 +602,9 @@ test_hang(int fd) > > > > gtt[0][x] = patterns[next_pattern]; > > gtt[1][x] = patterns[next_pattern]; > > + > > + if (READ_ONCE(control->done)) > > + break; > > The hang would have manifested itself on a previous loop > already. > > So you could life the exit condition before the writes. The writes may also cause a fresh fault. The idea was to simply check more frequently than once per object -- so long as we check within 2s of the termination request, we are good. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
