igt@gem_ctx_shared@exec-shared-gtt-blt - fail - Failed assertion: *s == 0xc0ffee

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8104/shard-tglb5/igt@gem_ctx_shared@exec-shared-gtt-blt.html

Starting subtest: exec-shared-gtt-blt
(gem_ctx_shared:1201) CRITICAL: Test assertion failure function exec_shared_gtt, file ../tests/i915/gem_ctx_shared.c:273:
(gem_ctx_shared:1201) CRITICAL: Failed assertion: *s == 0xc0ffee
(gem_ctx_shared:1201) CRITICAL: error: 0x5000000 != 0xc0ffee
Subtest exec-shared-gtt-blt failed.
**** DEBUG ****
(gem_ctx_shared:1201) ioctl_wrappers-DEBUG: Test requirement passed: gem_has_ring(fd, ring)
(gem_ctx_shared:1201) DEBUG: Test requirement passed: gem_can_store_dword(i915, ring)
(gem_ctx_shared:1201) CRITICAL: Test assertion failure function exec_shared_gtt, file ../tests/i915/gem_ctx_shared.c:273:
(gem_ctx_shared:1201) CRITICAL: Failed assertion: *s == 0xc0ffee
(gem_ctx_shared:1201) CRITICAL: error: 0x5000000 != 0xc0ffee
(gem_ctx_shared:1201) igt_core-INFO: Stack trace:
(gem_ctx_shared:1201) igt_core-INFO:   #0 ../lib/igt_core.c:1637 __igt_fail_assert()
(gem_ctx_shared:1201) igt_core-INFO:   #1 ../tests/i915/gem_ctx_shared.c:262 __real_main773()
(gem_ctx_shared:1201) igt_core-INFO:   #2 [<unknown>+0x0]
****  END  ****

added feature: GEM platform: TGL labels

The CI Bug Log issue associated to this bug has been updated by Lakshmi Vudum.

New filters associated

• igt@gem_ctx_shared@exec-shared-gtt-blt - fail - Failed assertion: *s == 0xc0ffee (No new failures associated)

added severity::critical label

There's a concern here that we've escaped from the vm.

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 112531b29f59..dbe993141c06 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -3095,7 +3095,7 @@ static int gen8_emit_init_breadcrumb(struct i915_request *rq)
         * After this point i915_request_started() reports true, even if
         * we get preempted and so are no longer running.
         */
-       *cs++ = MI_ARB_CHECK;
+       *cs++ = MI_ARB_CHECK | 1 << 8 | 1;
        *cs++ = MI_NOOP;
 
        *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;

real 7m29.741s

No joy.

mentioned in commit igt-gpu-tools@22daa038

Solved the reproducability issue,

commit 22daa038ffa737703a0e3076ac2aa475ea69ef00
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Mar 13 21:25:32 2020 +0000

    i915/gem_ctx_shared: Use a fence to group execution tightly
    
    Use a fence to submit the pair of batches tightly together, and in
    particular not allow the system time to retire in between. Then by
    passing the fence along the inter-context chain, we can force the
    explicit order of execution, which we currently lack as we are avoiding
    the implicit fences.
    
    In particular, without the explicit ordering the second batch could
    execute before the first had managed to asynchronously bind the hidden
    buffer.
    
    References: https://gitlab.freedesktop.org/drm/intel/issues/1420
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>

I thought the potential misordering of execution could have explained it... It fixed very random fail on Kabylake, but made Tigerlake much more consistent in detecting an error every time.

Mixed up version when testing; 'twas the fix. So the explanation was we were running the second batch before the first because they were unordered.

closed

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.