<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><span class="vcard"><a class="email" href="mailto:chris@chris-wilson.co.uk" title="Chris Wilson <chris@chris-wilson.co.uk>"> <span class="fn">Chris Wilson</span></a>
</span> changed
<a class="bz_bug_link
bz_status_NEEDINFO "
title="NEEDINFO --- - GPU HANG: ecode 0:0x85fffff8, in kwin [3405], reason: Ring hung, action: reset"
href="https://bugs.freedesktop.org/show_bug.cgi?id=84490">bug 84490</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>NEW
</td>
<td>NEEDINFO
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEEDINFO "
title="NEEDINFO --- - GPU HANG: ecode 0:0x85fffff8, in kwin [3405], reason: Ring hung, action: reset"
href="https://bugs.freedesktop.org/show_bug.cgi?id=84490#c1">Comment # 1</a>
on <a class="bz_bug_link
bz_status_NEEDINFO "
title="NEEDINFO --- - GPU HANG: ecode 0:0x85fffff8, in kwin [3405], reason: Ring hung, action: reset"
href="https://bugs.freedesktop.org/show_bug.cgi?id=84490">bug 84490</a>
from <span class="vcard"><a class="email" href="mailto:chris@chris-wilson.co.uk" title="Chris Wilson <chris@chris-wilson.co.uk>"> <span class="fn">Chris Wilson</span></a>
</span></b>
<pre>Should be fixed with
commit c4d69da167fa967749aeb70bc0e94a457e5d00c1
Author: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>>
Date: Mon Sep 8 14:25:41 2014 +0100
drm/i915: Evict CS TLBs between batches
Running igt, I was encountering the invalid TLB bug on my 845g, despite
that it was using the CS workaround. Examining the w/a buffer in the
error state, showed that the copy from the user batch into the
workaround itself was suffering from the invalid TLB bug (the first
cacheline was broken with the first two words reversed). Time to try a
fresh approach. This extends the workaround to write into each page of
our scratch buffer in order to overflow the TLB and evict the invalid
entries. This could be refined to only do so after we update the GTT,
but for simplicity, we do it before each batch.
I suspect this supersedes our current workaround, but for safety keep
doing both.
v2: The magic number shall be 2.
This doesn't conclusively prove that it is the mythical TLB bug we've
been trying to workaround for so long, that it requires touching a number
of pages to prevent the corruption indicates to me that it is TLB
related, but the corruption (the reversed cacheline) is more subtle than
a TLB bug, where we would expect it to read the wrong page entirely.
Oh well, it prevents a reliable hang for me and so probably for others
as well.
Signed-off-by: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>>
Cc: Daniel Vetter <<a href="mailto:daniel.vetter@ffwll.ch">daniel.vetter@ffwll.ch</a>>
Cc: Ville Syrjälä <<a href="mailto:ville.syrjala@linux.intel.com">ville.syrjala@linux.intel.com</a>>
Cc: <a href="mailto:stable@vger.kernel.org">stable@vger.kernel.org</a>
Reviewed-by: Daniel Vetter <<a href="mailto:daniel.vetter@ffwll.ch">daniel.vetter@ffwll.ch</a>>
Signed-off-by: Jani Nikula <<a href="mailto:jani.nikula@intel.com">jani.nikula@intel.com</a>>
I believe.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are on the CC list for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>