[Bug 111925] [CI][SHARDS]igt at gem_eio@in-flight-contexts-immediate|igt at gem_eio@in-flight-contexts-10ms - fail - Failed assertion: igt_seconds_elapsed(&ts) <= 10

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=111925

Chris Wilson <chris at chris-wilson.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|REOPENED                    |RESOLVED

--- Comment #6 from Chris Wilson <chris at chris-wilson.co.uk> ---
Next installment of this saga,
commit a64a29e775443e869e4524e5bd3a3427225810dc (upstream/master)
Author: Chris Wilson <chris at chris-wilson.co.uk>
Date:   Mon Nov 11 11:36:34 2019 +0000

    i915/gem_eio: Flush RCU before timing our own critical sections

    We cannot control how long RCU takes to find a quiescent point as that
    depends upon the background load and so may take an arbitrary time.
    Instead, let's try to avoid that impacting our measurements by inserting
    an rcu_barrier() before our critical timing sections and hope that hides
    the issue, letting us always perform a fast reset. Fwiw, we do the
    expedited RCU synchronize, but that is not always enough.

    Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
    Acked-by: Mika Kuoppala <mika.kuoppala at linux.intel.com>

Let's be brave and like all the other times assume that this fixes it for real.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20191111/64a62b58/attachment.html>