On CI_DRM_3054, the machine fi-gdg-551 hit the following assert when running igt@gem_exec_reloc@basic-gtt-read-active and igt@gem_exec_reloc@basic-gtt-cpu-active:
(gem_exec_reloc:1703) CRITICAL: Test assertion failure function basic_reloc, file gem_exec_reloc.c:394:
(gem_exec_reloc:1703) CRITICAL: Failed assertion: gem_bo_busy(fd, obj.handle)
Subtest basic-gtt-cpu-active failed.
Definitely on the impossible list.
Also seen here: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3071/fi-gdg-551/igt@email@example.com
And the opposite problem in #102654 (instead of the buffer not being busy, it doesn't become idle). If they are indeed two sides of the same coin, that says the spinbatch is as dodgy as an 14-sided pound coin.
Similar issues on:
(gem_exec_reloc:1681) CRITICAL: Test assertion failure function basic_reloc, file gem_exec_reloc.c:394:
(gem_exec_reloc:1681) CRITICAL: Failed assertion: gem_bo_busy(fd, obj.handle)
Subtest basic-write-gtt-active failed.
(gem_exec_reloc:1678) igt-dummyload-CRITICAL: Test assertion failure function __igt_spin_batch_new, file igt_dummyload.c:183:
(gem_exec_reloc:1678) igt-dummyload-CRITICAL: Failed assertion: gem_bo_busy(fd, spin->handle)
Subtest basic-write-cpu-active failed.
We've set noclflush on the gdg cmdline, so now we wait for a reoccurrence.
(In reply to Chris Wilson from comment #7)
> We've set noclflush on the gdg cmdline, so now we wait for a reoccurrence.
Chris, I was going to close and archive this, since the issue hasn't been seen since:
CI_DRM_3494: 2017-12-10 / 172 run ago.
However, you seem to want more info on this, so I leave it to you to close or keep it open. I will archive from cibuglog anyways.
I've no further ideas on how to determine the affected processors or why clflush isn't quite functioning correctly here. Given the limited impact, let's sweep this under the carpet and leave the noclflush w/a inplace.