[Bug 62191] New: Buffer Object corruption with multiple processes

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=62191

          Priority: medium
            Bug ID: 62191
          Assignee: intel-gfx-bugs at lists.freedesktop.org
           Summary: Buffer Object corruption with multiple processes
        QA Contact: intel-gfx-bugs at lists.freedesktop.org
          Severity: blocker
    Classification: Unclassified
                OS: Linux (All)
          Reporter: jon.bloomfield at intel.com
          Hardware: x86-64 (AMD64)
            Status: NEW
           Version: unspecified
         Component: DRM/Intel
           Product: DRI

Created attachment 76351
  --> https://bugs.freedesktop.org/attachment.cgi?id=76351&action=edit
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)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20130311/f87ac6a0/attachment.html>