https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5613/shard-glk1/igt@gem_exec_schedule@promotion-bsd.html Starting subtest: promotion-bsd (gem_exec_schedule:10027) CRITICAL: Test assertion failure function promotion, file ../tests/i915/gem_exec_schedule.c:408: (gem_exec_schedule:10027) CRITICAL: Failed assertion: result_read == ctx[2] (gem_exec_schedule:10027) CRITICAL: error: 0 != 0x3 https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5616/shard-glk9/igt@gem_exec_schedule@out-order-blt.html Starting subtest: out-order-blt (gem_exec_schedule:1538) CRITICAL: Test assertion failure function reorder, file ../tests/i915/gem_exec_schedule.c:355: (gem_exec_schedule:1538) CRITICAL: Failed assertion: result == ctx[0] (gem_exec_schedule:1538) CRITICAL: error: 0 != 0x1
The CI Bug Log issue associated to this bug has been updated. ### New filters associated * GLK: igt@gem_exec_schedule@promotion-bsd - fail - Failed assertion: result_read == ctx[2] - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5613/shard-glk1/igt@gem_exec_schedule@promotion-bsd.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5619/shard-glk4/igt@gem_exec_schedule@promotion-bsd.html * GLK: igt@gem_exec_schedule@out-order-(blt|vebox) - fail - Failed assertion: result == ctx[0] - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5616/shard-glk9/igt@gem_exec_schedule@out-order-blt.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5621/shard-glk2/igt@gem_exec_schedule@out-order-vebox.html
The important distinction here is the read result is 0. That means we read it before the result was written at all (not that the requests were out of order). So a GPU <-> CPU synchronization issue, all because we are telling porkies to the kernel and it doesn't know we are writing into the buffer and that it must flush any caches before reading. Regression from commit 7802324e86ddf947cba847e910f75b1a8affe8d7 Author: Antonio Argenziano <antonio.argenziano@intel.com> Date: Fri Feb 15 07:42:02 2019 -0800 tests/i915/gem_exec_schedule.c: Switch to gem_sync and gem_read as gem_sync isn't enough -- mea culpa.
commit c12b1f87adc4c568b21cc6ed9076b94bea46b010 (HEAD, upstream/master) Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Feb 17 18:14:01 2019 +0000 i915/gem_exec_schedule: Switch back to gem_set_domain() The write hazard lies extend also to the cache-dirty tracking; as we purposefully do not tell the kernel we are writing to the bo, it fails to note the CPU cache as dirty and so the gem_read() may not sufficiently flush the caches prior to reading back from the GPU. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Antonio Argenziano <antonio.argenziano@intel.com> Reviewed-by: Antonio Argenziano <antonio.argenziano@intel.com> Should be back to where we were... Albeit with the subtle difference between gem_read and gem_mmap__gtt...
The CI Bug Log issue associated to this bug has been updated. ### New filters associated * APL: igt@gem_exec_schedule@in-order-bsd - fail - Failed assertion: result == ctx[1] - https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4838/shard-apl7/igt@gem_exec_schedule@in-order-bsd.html
(In reply to CI Bug Log from comment #4) > The CI Bug Log issue associated to this bug has been updated. > > ### New filters associated > > * APL: igt@gem_exec_schedule@in-order-bsd - fail - Failed assertion: result > == ctx[1] > - > https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4838/shard-apl7/ > igt@gem_exec_schedule@in-order-bsd.html This happened before the fix from Chris. So let's keep the bug closed. Chris, thanks a lot for your fix!
*** Bug 109722 has been marked as a duplicate of this bug. ***
The CI Bug Log issue associated to this bug has been archived. New failures matching the above filters will not be associated to this bug anymore.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.