Started at CI_DRM_3365 SNB-shards, also on CI_DRM_3366, potential regression. https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3365/shard-snb2/igt@gem_busy@close-race.html (gem_busy:1645) CRITICAL: Test assertion failure function busy_blt, file gem_busy.c:129: (gem_busy:1645) CRITICAL: Failed assertion: gem_bo_busy(fd, object[0].handle) Subtest close-race failed.
It's just the test making an assertion on a handle in one thread after closing it in another. That test is particularly tricky because we keep trying to use common functions that assert success (when the test is intentionally causing failures).
Reference: https://patchwork.freedesktop.org/series/34818/
commit 7e07894d8b0f567cb4241b5bed8a9644874ddd47 (HEAD, upstream/master) Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Dec 1 21:53:03 2017 +0000 igt/gem_busy: Replace arbitrary busy batch with indefinite spinbatch In CI, we were observing situations where the busy blt would complete before the very next instruction (in userspace) to assert that it was busy. This is entirely possible if the process was scheduled away and slept for longer than the arbitrary batch. Instead replace arbitrariness with a precise infinity. v2: Be respectful to UP! v3: Move spinbatch to owning process to avoid serialisation delays. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103829 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (Hopefully)
Fix included in CI_DRM_3449, I will close
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.