[Bug 106342] [drm] HANG: ecode 9:0:0x9cba0f27, in kscreenlocker_g [103585], reason: Hang on rcs0, action: reset

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri May 11 17:27:45 UTC 2018


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

--- Comment #11 from Chris Wilson <chris at chris-wilson.co.uk> ---
(In reply to Thiago Macieira from comment #10)
> Created attachment 139501 [details]
> card0_error 2018-05-11

That one is a regular userspace hang.

With respect to the earlier hangs, we've just applied

commit 77dfedb5be03779f9a5d83e323a1b36e32090105
Author: Chris Wilson <chris at chris-wilson.co.uk>
Date:   Fri May 11 13:11:45 2018 +0100

    drm/i915/execlists: Use rmb() to order CSB reads

    We assume that the CSB is written using the normal ringbuffer
    coherency protocols, as outlined in kernel/events/ring_buffer.c:

        *   (HW)                              (DRIVER)
        *
        *   if (LOAD ->data_tail) {            LOAD ->data_head
        *                      (A)             smp_rmb()       (C)
        *      STORE $data                     LOAD $data
        *      smp_wmb()       (B)             smp_mb()        (D)
        *      STORE ->data_head               STORE ->data_tail
        *   }

    So we assume that the HW fulfils its ordering requirements (B), and so
    we should use a complimentary rmb (C) to ensure that our read of its
    WRITE pointer is completed before we start accessing the data.

    The final mb (D) is implied by the uncached mmio we perform to inform
    the HW of our READ pointer.

to drm-tip which may explain why we didn't drain ELSP.

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


More information about the intel-gfx-bugs mailing list