<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [CI] igt@gem_mmap_gtt@forked-* - Failed assertion: page[j] == i + j -" href="https://bugs.freedesktop.org/show_bug.cgi?id=105591#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [CI] igt@gem_mmap_gtt@forked-* - Failed assertion: page[j] == i + j -" href="https://bugs.freedesktop.org/show_bug.cgi?id=105591">bug 105591</a> from <a class="email" href="mailto:chris@chris-wilson.co.uk" title="Chris Wilson <chris@chris-wilson.co.uk>"> Chris Wilson</a> <pre>I think we may need to undo commit 4509276ee824bb967885c095c610767e42345c36 Author: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>> Date: Mon Feb 20 12:47:18 2017 +0000 drm/i915: Remove Braswell GGTT update w/a Testing with concurrent GGTT accesses no longer show the coherency problems from yonder, commit 5bab6f60cb4d ("drm/i915: Serialise updates to GGTT with access through GGTT on Braswell"). My presumption is that the root cause was more likely fixed by commit 3b5724d702ef ("drm/i915: Wait for writes through the GTT to land before reading back"), along with the use of WC updates to the global gTT in commit 8448661d65f6 ("drm/i915: Convert clflushed pagetables over to WC maps". Given that the original symptoms can no longer be reproduced, time to remove the workaround. and so restore commit 5bab6f60cb4d1417ad7c599166bcfec87529c1a2 Author: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>> Date: Fri Oct 23 18:43:32 2015 +0100 drm/i915: Serialise updates to GGTT with access through GGTT on Braswell When accessing through the GTT from one CPU whilst concurrently updating the GGTT PTEs in another thread, the hardware likes to return random data. As we have strong serialisation prevent us from modifying the PTE of an active GTT mmapping, we have to conclude that it whilst modifying other PTE's that error occurs. (I have not looked for any pattern such as modifying PTE within the same page or cacheline as active PTE - though checking whether revoking neighbouring objects should be enough to test that theory.) The corruption also seems restricted to Braswell and disappears with maxcpus=0. This patch stops all access through the GTT by other CPUs when we update any PTE by stopping the machine around the GGTT update. Note that splitting up the 64 bit write into two 32 bit writes was tried and found to fail too.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>