[Intel-gfx] [PATCH i-g-t] i915/gem_exec_schedule: Exercise resolving of userspace semaphores

[Chris Wilson]

Quoting Mika Kuoppala (2019-04-25 11:40:13)
> Chris Wilson <chris at chris-wilson.co.uk> writes:
> > +             /* Now the semaphore is spinning, cancel it */
> > +             cancel = gem_create(i915, 4096);
> > +             cs = map = gem_mmap__cpu(i915, cancel, 0, 4096, PROT_WRITE);
> > +             *cs++ = MI_STORE_DWORD_IMM;
> > +             *cs++ = SEMAPHORE_ADDR;
> > +             *cs++ = 0;
> > +             *cs++ = 0;
> > +             *cs++ = MI_BATCH_BUFFER_END;
> > +             munmap(map, 4096);
> > +
> > +             memset(obj, 0, sizeof(obj));
> > +             obj[0].handle = semaphore;
> > +             obj[0].offset = SEMAPHORE_ADDR;
> > +             obj[0].flags = EXEC_OBJECT_PINNED;
> > +             obj[1].handle = cancel;
> > +             eb.buffer_count = 2;
> > +             eb.rsvd1 = inner;
> > +             gem_execbuf(i915, &eb);
> > +             gem_close(i915, cancel);
> > +
> > +             gem_sync(i915, handle); /* To hang unless cancel runs! */
> 
> Ok, well I am not exactly sure about the march order on here
> onwards. I mean that if the timeslicing is not yet there,
> we need to embrace the hang as a success?

It's just a known failure to be fixed. So long as it doesn't flip-flop,
only those looking at the failure reports (not the issues listed in the
CI summaries), cibuglog and bugzilla get annoyed.
 
> Tho perhaps the march...merge order is better discussed
> in the context of actual kernel side patch.

Much nicer to be able to point to a test failure being fixed, gives the
green jollies.
-Chris