[Bug 109606] [CI][DRMTIP] igt at pm_rps@reset - dmesg-fail - Failed assertion: __gem_execbuf_wr(fd, execbuf) == 0

[bugzilla-daemon at freedesktop.org]

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

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

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

--- Comment #4 from Chris Wilson <chris at chris-wilson.co.uk> ---
commit 89531e7d8ee8602b2723431a581250d5d0ec2913
Author: Chris Wilson <chris at chris-wilson.co.uk>
Date:   Tue Feb 26 09:49:19 2019 +0000

    drm/i915: Replace global_seqno with a hangcheck heartbeat seqno

    To determine whether an engine has 'stuck', we simply check whether or
    not is still on the same seqno for several seconds. To keep this simple
    mechanism intact over the loss of a global seqno, we can simply add a
    new global heartbeat seqno instead. As we cannot know the sequence in
    which requests will then be completed, we use a primitive random number
    generator instead (with a cycle long enough to not matter over an
    interval of a few thousand requests between hangcheck samples).

    The alternative to using a dedicated seqno on every request is to issue
    a heartbeat request and query its progress through the system. Sadly
    this requires us to reduce struct_mutex so that we can issue requests
    without requiring that bkl.

    v2: And without the extra CS_STALL for the hangcheck seqno -- we don't
    need strict serialisation with what comes later, we just need to be sure
    we don't write the hangcheck seqno before our batch is flushed.

    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>
    Link:
https://patchwork.freedesktop.org/patch/msgid/20190226094922.31617-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/20190226/7bdff20a/attachment.html>