[Bug 110913] [CI][SHARDS] Igt@* - dmesg-warn - WARNING: possible circular locking dependency detected

[bugzilla-daemon at freedesktop.org]

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

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

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

--- Comment #8 from Chris Wilson <chris at chris-wilson.co.uk> ---
commit de5147b8ce6d51f634661d7c531385371485cec6
Author: Chris Wilson <chris at chris-wilson.co.uk>
Date:   Wed Jun 26 16:45:47 2019 +0100

    drm/i915: Add a wakeref getter for iff the wakeref is already active

    For use in the next patch, we want to acquire a wakeref without having
    to wake the device up -- i.e. only acquire the engine wakeref if the
    engine is already active.

    Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
    Reviewed-by: Mika Kuoppala <mika.kuoppala at linux.intel.com>
    Link:
https://patchwork.freedesktop.org/patch/msgid/20190626154549.10066-1-chris@chris-wilson.co.uk

commit 18398904ca9e3ddd180e2ecd45886e146b1d9d5b
Author: Chris Wilson <chris at chris-wilson.co.uk>
Date:   Wed Jun 26 16:45:48 2019 +0100

    drm/i915: Only recover active engines

    If we issue a reset to a currently idle engine, leave it idle
    afterwards. This is useful to excise a linkage between reset and the
    shrinker. When waking the engine, we need to pin the default context
    image which we use for overwriting a guilty context -- if the engine is
    idle we do not need this pinned image! However, this pinning means that
    waking the engine acquires the FS_RECLAIM, and so may trigger the
    shrinker. The shrinker itself may need to wait upon the GPU to unbind
    and object and so may require services of reset; ergo we should avoid
    the engine wake up path.

    The danger in skipping the recovery for idle engines is that we leave the
    engine with no context defined, which may interfere with the operation of
    the power context on some older platforms. In practice, we should only
    be resetting an active GPU but it something to look out for on Ironlake
    (if memory serves).

    Fixes: 79ffac8599c4 ("drm/i915: Invert the GEM wakeref hierarchy")
    Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
    Reviewed-by: Mika Kuoppala <mika.kuoppala at linux.intel.com>
    Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
    Cc: Imre Deak <imre.deak at intel.com>
    Link:
https://patchwork.freedesktop.org/patch/msgid/20190626154549.10066-2-chris@chris-wilson.co.uk

commit 092be382a2602067766f190a113514d469162456 (HEAD -> drm-intel-next-queued,
drm-intel/for-linux-next, drm-intel/drm-intel-next-queued)
Author: Chris Wilson <chris at chris-wilson.co.uk>
Date:   Wed Jun 26 16:45:49 2019 +0100

    drm/i915: Lift intel_engines_resume() to callers

    Since the reset path wants to recover the engines itself, it only wants
    to reinitialise the hardware using i915_gem_init_hw(). Pull the call to
    intel_engines_resume() to the module init/resume path so we can avoid it
    during reset.

    Fixes: 79ffac8599c4 ("drm/i915: Invert the GEM wakeref hierarchy")
    Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
    Reviewed-by: Mika Kuoppala <mika.kuoppala at linux.intel.com>
    Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
    Cc: Imre Deak <imre.deak at intel.com>
    Link:
https://patchwork.freedesktop.org/patch/msgid/20190626154549.10066-3-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/20190626/7b1fbf69/attachment.html>