[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