[Bug 109626] [CI][SHARDS] igt at i915_selftest@live_workarounds - incomplete

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Feb 15 09:54:26 UTC 2019


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

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

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

--- Comment #3 from Chris Wilson <chris at chris-wilson.co.uk> ---
commit c836eb79c033c2be13aa8b41729b28d2ab1f72ab (HEAD -> drm-intel-next-queued,
drm-intel/drm-intel-next-queued)
Author: Chris Wilson <chris at chris-wilson.co.uk>
Date:   Wed Feb 13 22:48:05 2019 +0000

    drm/i915/selftests: Always use an active engine while resetting

    Currently, we only try to reset a live engine for checking the whitelist
    retention across a per-engine reset. For safety, it appears we need to
    prime the system with a hanging spinner before performing a full-device
    reset. (Figuring out the root cause behind the instability with handling
    a reset during a no-op request is a challenge for another test, the
    whitelist test has its own purpose.)

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109626
    Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
    Link:
https://patchwork.freedesktop.org/patch/msgid/20190213224805.32021-1-chris@chris-wilson.co.uk
    Reviewed-by: Mika Kuoppala <mika.kuoppala at linux.intel.com>

should prevent it from occurring, and CI hints that

commit 9a3b19a16dc28ab717cf1663d09ffee0715b735a
Author: Chris Wilson <chris at chris-wilson.co.uk>
Date:   Wed Feb 13 23:20:47 2019 +0000

    drm/i915: Only try to park engines after a failed reset

    Currently we try to stop the engine by programming the ring registers to
    be disabled before we perform the reset. Sometimes, we see the context
    image also have invalid ring registers, which one presumes may be
    actually caused by us doing so. Lets risk not doing programming the
    ring to zero on the first attempt to avoid preserving that corruption
    into the context image, leaving the w/a in place for subsequent
    reset attempts.

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

might be the real deal.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list 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/20190215/6cc81f37/attachment-0001.html>


More information about the intel-gfx-bugs mailing list