|Summary:||[CI] igt@gem_busy@close-race - fail - Failed assertion: gem_bo_busy(fd, object.handle)|
|Product:||DRI||Reporter:||Marta Löfstedt <marta.lofstedt>|
|Component:||IGT||Assignee:||Default DRI bug account <dri-devel>|
|Status:||CLOSED FIXED||QA Contact:|
|i915 platform:||SNB||i915 features:||GEM/Other|
Description Marta Löfstedt 2017-11-21 07:02:55 UTC
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@firstname.lastname@example.org (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.handle) Subtest close-race failed.
Comment 1 Chris Wilson 2017-11-21 10:00:30 UTC
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).
Comment 2 Jani Saarinen 2017-12-04 10:26:57 UTC
Comment 3 Chris Wilson 2017-12-04 14:33:04 UTC
commit 7e07894d8b0f567cb4241b5bed8a9644874ddd47 (HEAD, upstream/master) Author: Chris Wilson <email@example.com> 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 <firstname.lastname@example.org> Reviewed-by: Joonas Lahtinen <email@example.com> (Hopefully)
Comment 4 Marta Löfstedt 2017-12-05 08:41:44 UTC
Fix included in CI_DRM_3449, I will close