Re: [igt-dev] [PATCH i-g-t] i915/gem_exec_schedule: Exercise resolving of userspace semaphores

Chris Wilson
2019-04-25T11:16:21Z

Quoting Mika Kuoppala (2019-04-25 11:40:13)
> Chris Wilson <chris@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