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. -Mika > } > > last_pattern = next_pattern; > -- > 2.23.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
