<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Buffer Object corruption with multiple processes"
href="https://bugs.freedesktop.org/show_bug.cgi?id=62191">62191</a>
</td>
</tr>
<tr>
<th>Assignee</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Summary</th>
<td>Buffer Object corruption with multiple processes
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Severity</th>
<td>blocker
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Reporter</th>
<td>jon.bloomfield@intel.com
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86-64 (AMD64)
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Component</th>
<td>DRM/Intel
</td>
</tr>
<tr>
<th>Product</th>
<td>DRI
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=76351" name="attach_76351" title="drm buffer object bug demo program">attachment 76351</a> <a href="attachment.cgi?id=76351&action=edit" title="drm buffer object bug demo program">[details]</a></span>
drm buffer object bug demo program
When several processes attempt to use gem buffer objects simultaneously data
written to the buffers is occasionally lost.
The attached C program, selftest.c, demonstrates the issue. The program spawns
1 or more child processes each of which runs exactly the same test sequence:
create tiled buffer object
loop 10 times
map buffer to gtt
fill buffer with unique data, and verify each write immediately (A)
unmap buffer
map buffer to gtt
readback and verify data in buffer (B)
unmap buffer
end loop
When run with more than about 20 test processes the readback of written data
occasionally fails. The chance of errors being introduced increases with the
number of processes.
Note that the program verifies the data in two places. Once as each DWord of
data is written to the buffer (A), and again in a separate pass after the
entire buffer has been filled. If an error is detected at (A) the child exits,
so any errors reported at (B) imply that the data did originally write
correctly to the buffer, but has subsequently been lost.
Each processes data is unique, and is formed by the DWord offset in the lower 5
nibbles, followed by the loop counter in the 6th nibble, and finally the
process instance in the upper byte.
In all failures I have seen to date no cross-process corruption has occurred.
The erroneous data always corresponds to data previously written by the SAME
process, usually from a previous iteration of the loop.
Latest kernel tested: 3.8.0-RC6+ from
git://people.freedesktop.org/~danvet/drm-intel (2013-03-07)</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 the assignee for the bug.</li>
</ul>
</body>
</html>