<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><span class="vcard"><a class="email" href="mailto:notasas@gmail.com" title="Grazvydas Ignotas <notasas@gmail.com>"> <span class="fn">Grazvydas Ignotas</span></a>
</span> changed
<a class="bz_bug_link
bz_status_NEW "
title="NEW - Tonga GPU lock/reset fail with Unigine Valley"
href="https://bugs.freedesktop.org/show_bug.cgi?id=91278">bug 91278</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;">CC</td>
<td>
</td>
<td>notasas@gmail.com
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Tonga GPU lock/reset fail with Unigine Valley"
href="https://bugs.freedesktop.org/show_bug.cgi?id=91278#c34">Comment # 34</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Tonga GPU lock/reset fail with Unigine Valley"
href="https://bugs.freedesktop.org/show_bug.cgi?id=91278">bug 91278</a>
from <span class="vcard"><a class="email" href="mailto:notasas@gmail.com" title="Grazvydas Ignotas <notasas@gmail.com>"> <span class="fn">Grazvydas Ignotas</span></a>
</span></b>
<pre>Created <span class=""><a href="attachment.cgi?id=118824" name="attach_118824" title="test kernel patch">attachment 118824</a> <a href="attachment.cgi?id=118824&action=edit" title="test kernel patch">[details]</a></span> <a href='page.cgi?id=splinter.html&bug=91278&attachment=118824'>[review]</a>
test kernel patch
(In reply to Michel Dänzer from <a href="show_bug.cgi?id=91278#c29">comment #29</a>)
<span class="quote">> That is interesting, though; the radeonsi driver seems to think there should
> be something mapped at the faulting address. This indicates that either the
> kernel driver fails to handle the mapping properly, or maybe there's a
> problem with communicating the buffer mapping information from userspace to
> the kernel driver.</span >
Judging by the symptoms it feels like some caching/buffering problem somewhere.
If I understand the code right, most of things are mapped write-combine, which
means the CPU is allowed to write data it any order it likes. Looking at
amdgpu/radeon code, there is surprising lack of barriers, basically it's just
amdgpu_ring_commit()/radeon_ring_commit() and that's it. But mb() doesn't
guarantee that the writes will arrive in program order, it just ensures that
all the writes are finished after that mb() statement.
So the question is, is it ok for the hardware if in something like
amdgpu_ib_schedule() the writes to the ring arrive before the writes to IB? I
do admit I don't understand how the hardware works, like what triggers the
hardware to start processing the ring contents, perhaps the write to the last
word in the ring? If so you clearly need a wmb() before the write which
triggers the hardware so that everything is ready before the GPU kicks in.
Attached is a debug kernel patch to test if my guess is correct. It's way
overkill and will trash performance, but it should show if this is a problem
related to CPU caching/buffering. I don't have the hardware to test this
myself.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>