[Bug 90537] radeonsi bo/va conflict on RADEON_GEM_VA (rscreen->ws->buffer_from_handle returns NULL)

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed May 20 07:06:42 PDT 2015


            Bug ID: 90537
           Summary: radeonsi bo/va conflict on RADEON_GEM_VA
                    (rscreen->ws->buffer_from_handle returns NULL)
           Product: Mesa
           Version: 10.5
          Hardware: x86 (IA32)
                OS: other
            Status: NEW
          Severity: trivial
          Priority: medium
         Component: Drivers/Gallium/radeonsi
          Assignee: dri-devel at lists.freedesktop.org
          Reporter: pstglia at gmail.com
        QA Contact: dri-devel at lists.freedesktop.org

Created attachment 115927
  --> https://bugs.freedesktop.org/attachment.cgi?id=115927&action=edit
dmesg output (drm.debug=7)

Hi, we're trying to make radeonsi work on Android-x86 (porting of AOSP to x86

We can have graphical output, but at some circunstances (certain apps, like
Antutu Benchmark) we are receiving a "radeon bo/va conflict with bo/va" from
kernel. When this happens, graphical components crashes.

As I could check, This error occurs on "r600_texture_from_handle" (which is
being called on native_android.cpp gallium state tracker;
screen->resource_from_handle - use_drm is set ) 

When calling "rscreen->ws->buffer_from_handle" NULL is being returned. From
kernel dmesg (drm.debug = 7), we get this ioctl error:

<7>[  244.847256] [drm:drm_ioctl] pid=3469, dev=0xe200, auth=0,
<7>[  244.847269] [drm:drm_ioctl] pid=3469, dev=0xe200, auth=0,
<7>[  244.848972] [drm:drm_ioctl] pid=4171, dev=0xe200, auth=0,
<7>[  244.849030] [drm:drm_ioctl] pid=4171, dev=0xe200, auth=0, RADEON_GEM_VA
<7>[  244.849084] [drm:drm_ioctl] pid=4171, dev=0xe200, auth=0, RADEON_GEM_MMAP
<7>[  244.849150] [drm:drm_ioctl] pid=4171, dev=0xe200, auth=0,
<7>[  244.849177] [drm:drm_ioctl] pid=4171, dev=0xe200, auth=0, RADEON_GEM_VA
<3>[  244.849191] radeon 0000:00:01.0: bo ccf78800 va 0x0000000858 conflict
with (bo cec3a000 0x0000000869 0x000000086a)
<7>[  244.849199] [drm:drm_ioctl] ret = -22
<7>[  244.849251] [drm:drm_ioctl] pid=4171, dev=0xe200, auth=0,
<7>[  244.853770] [drm:drm_release] open_count = 5
<7>[  244.853782] [drm:drm_release] pid = 3464, device = 0xe200, open_count = 5

I suppose this "buffer_from_handle" in this case is mapped with
"radeon_winsys_bo_from_handle" function. If this assumption is correct, the
error is occuring during this call:

        va.handle = bo->handle;
        va.operation = RADEON_VA_MAP;
        va.vm_id = 0;
        va.offset = bo->va;
        va.flags = RADEON_VM_PAGE_READABLE |
                   RADEON_VM_PAGE_WRITEABLE |
        va.offset = bo->va;
        r = drmCommandWriteRead(ws->fd, DRM_RADEON_GEM_VA, &va, sizeof(va));
        if (r && va.operation == RADEON_VA_RESULT_ERROR) {
            fprintf(stderr, "radeon: Failed to assign virtual address
            return NULL;

I tried using kernel 4.0.3 (which contains some kernel patches apparently
related to this):

drm/radeon: fix lockup when BOs aren't part of the VM on release 
drm/radeon: reset BOs address after clearing it. 
drm/radeon: check new address before removing old one 

But the same error happens.

I'd like some help in order to find out what's wrong (bug on Mesa/drm or wrong
config at Android side):

- I'm building for a 32 bits environment. Does this can cause the problem I
described? Maybe the driver/drm/mesa works better on a 64 bits environment?

- For graphical buffer management (alloc, map, unmap, etc) we have drm_gralloc,
which is based on xf86-video-ati. If possible, can you take a quick look an see
if there's something that needs to changed in particullar for
radeonsi?(gralloc_drm_radeon.c on

Any help is appreciated. Thank you!

ps: It's working nice with r600g driver/hardware

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150520/9be9c29e/attachment.html>

More information about the dri-devel mailing list