[Bug 110520] [CI][SHARDS] igt at i915_selftest@live_evict - incomplete - RIP: \d+:__queue_work

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Jul 8 08:42:29 UTC 2019


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

--- Comment #4 from Martin Peres <martin.peres at free.fr> ---
(In reply to Chris Wilson from comment #3)
> commit dc76e5764a46ffb2e7f502a86b3288b5edcce191 (HEAD ->
> drm-intel-next-queued, drm-intel/drm-intel-next-queued)
> Author: Chris Wilson <chris at chris-wilson.co.uk>
> Date:   Wed May 1 14:57:51 2019 +0100
> 
>     drm/i915: Complete both freed-object passes before draining the workqueue
>     
>     The workqueue code complains viciously if we try to queue more work onto
>     the queue while attampting to drain it. As we asynchronously free
>     objects and defer their enqueuing with RCU, it is quite tricky to
>     quiesce the system before attempting to drain the workqueue. Yet drain
>     we must to ensure that the worker is idle before unloading the module.
>     
>     Give the freed object drain 3 whole passes with multiple rcu_barrier()
>     to give the defer freeing of several levels each protected by RCU and
>     needing a grace period before its parent can be freed, ultimately
>     resulting in a GEM object being freed after another RCU period.
>     
>     A consequence is that it will make module unload even slower.
>     
>     Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110550
>     Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
>     Reviewed-by: Matthew Auld <matthew.auld at intel.com>
>     Link:
> https://patchwork.freedesktop.org/patch/msgid/20190501135753.8711-1-
> chris at chris-wilson.co.uk

Thanks, it did the trick!

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


More information about the intel-gfx-bugs mailing list