On Sun, Sep 09, 2018 at 01:43:08PM +0100, Chris Wilson wrote: > A missing no-op causing us to emit the wrong address when relocation was > required for BB_START. > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > --- > tests/gem_exec_capture.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/tests/gem_exec_capture.c b/tests/gem_exec_capture.c > index 2dc06ce43..9c26e12c9 100644 > --- a/tests/gem_exec_capture.c > +++ b/tests/gem_exec_capture.c > @@ -117,7 +117,7 @@ static void __capture(int fd, int dir, unsigned ring, uint32_t target) > batch[++i] = 0; > } > batch[++i] = 0xc0ffee; > - if (gen < 3) > + if (gen <= 3) > batch[++i] = MI_NOOP; This code is rather well obfuscated. Removing the length from MI_STORE_DWORD_IMM and just setting it correctly in each branch would go a long way towards making things more obvious. > > batch[++i] = MI_BATCH_BUFFER_START; /* not crashed? try again! */ > @@ -144,10 +144,12 @@ static void __capture(int fd, int dir, unsigned ring, uint32_t target) > execbuf.flags = ring; > if (gen > 3 && gen < 6) > execbuf.flags |= I915_EXEC_SECURE; > + > + igt_assert(!READ_ONCE(*seqno)); > gem_execbuf(fd, &execbuf); > > /* Wait for the request to start */ > - while (*(volatile uint32_t *)seqno != 0xc0ffee) > + while (READ_ONCE(*seqno) != 0xc0ffee) > igt_assert(gem_bo_busy(fd, obj[SCRATCH].handle)); > munmap(seqno, 4096); > > -- > 2.19.0.rc2 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx