Quoting Mika Kuoppala (2019-04-25 11:40:13) > Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
