[Bug 105957] [CI] igt at gem_eio@* - fail - Test assertion failure function trigger_reset - Failed assertion: igt_seconds_elapsed(&ts) < 2
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Thu May 17 22:34:10 UTC 2018
https://bugs.freedesktop.org/show_bug.cgi?id=105957
Chris Wilson <chris at chris-wilson.co.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #2 from Chris Wilson <chris at chris-wilson.co.uk> ---
commit 89ae332745e31a075747a63ac5acc5baccf75769
Author: Chris Wilson <chris at chris-wilson.co.uk>
Date: Fri May 11 18:58:59 2018 +0100
tests/gem_eio: Only wait-for-idle inside trigger_reset()
trigger_reset() imposes a tight time constraint (2s) so that we verify
that the reset itself completes quickly. In the middle of this check, we
call gem_quiescent_gpu() which may invoke an rcu_barrier() or two to
clear out the freed memory (DROP_FREED). Those barriers may have
unbounded latency pushing beyond the 2s timeout, so restrict the
operation to only wait-for-idle (DROP_ACTIVE).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105957
Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
Optimistically marking as fixed to see what happens. It's doubtful that the
rcu_barrier alone is causing the grief, so I suspect there might be an outside
timing influence -- as far as I can tell, the driver is doing the right thing
and isn't causing the delay itself.
--
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/20180517/785bdb7d/attachment.html>
More information about the intel-gfx-bugs
mailing list