Bug 107770 - [CI][DRMTIP] igt@gem_exec_parallel@blt-fds - fail - Failed assertion: map[i] == i
Summary: [CI][DRMTIP] igt@gem_exec_parallel@blt-fds - fail - Failed assertion: map[i] ...
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: Other All
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-31 14:10 UTC by Martin Peres
Modified: 2018-09-07 15:33 UTC (History)
1 user (show)

See Also:
i915 platform: BYT
i915 features: GEM/Other


Attachments

Description Martin Peres 2018-08-31 14:10:45 UTC
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_92/fi-byt-j1900/igt@gem_exec_parallel@blt-fds.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_93/fi-byt-j1900/igt@gem_exec_parallel@blt-fds.html

(gem_exec_parallel:1259) CRITICAL: Test assertion failure function check_bo, file ../tests/gem_exec_parallel.c:54:
(gem_exec_parallel:1259) CRITICAL: Failed assertion: map[i] == i
(gem_exec_parallel:1259) CRITICAL: error: 0 != 583
Comment 1 Chris Wilson 2018-08-31 14:13:28 UTC
Same suspect as

commit 70b73f9ac113983f9c7db9887447f1344ac5b69b
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Aug 30 17:10:42 2018 +0100

    drm/i915/ringbuffer: Delay after invalidating gen6+ xcs
    
    During stress testing of full-ppgtt (on Baytrail at least), we found
    that the invalidation around a context/mm switch was insufficient (writes
    would go astray). Adding a second MI_FLUSH_DW barrier prevents this, but
    it is unclear as to whether this is merely a delaying tactic or if it is
    truly serialising with the TLB invalidation. Either way, it is
    empirically required.
    
    v2: Avoid the loop for readability;
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107715
    References: https://bugs.freedesktop.org/show_bug.cgi?id=107759
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
    Cc: Matthew Auld <matthew.william.auld@gmail.com>
    Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20180830161042.29193-1-chris@chris-wilson.co.uk

As with the others, lets see what happens now.
Comment 2 Martin Peres 2018-09-07 15:33:06 UTC
(In reply to Chris Wilson from comment #1)
> Same suspect as
> 
> commit 70b73f9ac113983f9c7db9887447f1344ac5b69b
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Thu Aug 30 17:10:42 2018 +0100
> 
>     drm/i915/ringbuffer: Delay after invalidating gen6+ xcs
>     
>     During stress testing of full-ppgtt (on Baytrail at least), we found
>     that the invalidation around a context/mm switch was insufficient (writes
>     would go astray). Adding a second MI_FLUSH_DW barrier prevents this, but
>     it is unclear as to whether this is merely a delaying tactic or if it is
>     truly serialising with the TLB invalidation. Either way, it is
>     empirically required.
>     
>     v2: Avoid the loop for readability;
>     
>     Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107715
>     References: https://bugs.freedesktop.org/show_bug.cgi?id=107759
>     Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>     Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>     Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
>     Cc: Matthew Auld <matthew.william.auld@gmail.com>
>     Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>     Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>     Link:
> https://patchwork.freedesktop.org/patch/msgid/20180830161042.29193-1-
> chris@chris-wilson.co.uk
> 
> As with the others, lets see what happens now.

Looks like it fixed it! It uised to happen almost every run, and now nothing in 10 runs. Closing!


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.