[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
Wed May 1 21:37:52 UTC 2019


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

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

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

--- Comment #3 from Chris Wilson <chris at chris-wilson.co.uk> ---
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@chris-wilson.co.uk

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


More information about the intel-gfx-bugs mailing list