From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 90537] radeonsi bo/va conflict on RADEON_GEM_VA (rscreen->ws->buffer_from_handle returns NULL) Date: Wed, 20 May 2015 14:06:42 +0000 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1963437782==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 3256C6E77F for ; Wed, 20 May 2015 07:06:42 -0700 (PDT) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1963437782== Content-Type: multipart/alternative; boundary="1432130802.5B2dF1A0.7187"; charset="UTF-8" --1432130802.5B2dF1A0.7187 Date: Wed, 20 May 2015 14:06:42 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" https://bugs.freedesktop.org/show_bug.cgi?id=90537 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@lists.freedesktop.org Reporter: pstglia@gmail.com QA Contact: dri-devel@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 architecture). 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, DRM_IOCTL_GEM_CLOSE <7>[ 244.847269] [drm:drm_ioctl] pid=3469, dev=0xe200, auth=0, DRM_IOCTL_GEM_CLOSE <7>[ 244.848972] [drm:drm_ioctl] pid=4171, dev=0xe200, auth=0, RADEON_GEM_CREATE <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, RADEON_GEM_CREATE <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, DRM_IOCTL_GEM_CLOSE <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 | RADEON_VM_PAGE_SNOOPED; 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 space\n"); radeon_bo_destroy(&bo->base); 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 http://git.android-x86.org/?p=platform/hardware/drm_gralloc.git;a=tree;h=refs/heads/lollipop-x86;hb=refs/heads/lollipop-x86) Any help is appreciated. Thank you! pstglia ps: It's working nice with r600g driver/hardware -- You are receiving this mail because: You are the assignee for the bug. --1432130802.5B2dF1A0.7187 Date: Wed, 20 May 2015 14:06:42 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8"
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@lists.freedesktop.org
Reporter pstglia@gmail.com
QA Contact dri-devel@lists.freedesktop.org

Created attachment 115927 [details]
dmesg output (drm.debug=7)

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

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,
DRM_IOCTL_GEM_CLOSE
<7>[  244.847269] [drm:drm_ioctl] pid=3469, dev=0xe200, auth=0,
DRM_IOCTL_GEM_CLOSE
<7>[  244.848972] [drm:drm_ioctl] pid=4171, dev=0xe200, auth=0,
RADEON_GEM_CREATE
<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,
RADEON_GEM_CREATE
<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,
DRM_IOCTL_GEM_CLOSE
<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 |
                   RADEON_VM_PAGE_SNOOPED;
        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
space\n");
            radeon_bo_destroy(&bo->base);
            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
http://git.android-x86.org/?p=platform/hardware/drm_gralloc.git;a=tree;h=refs/heads/lollipop-x86;hb=refs/heads/lollipop-x86)

Any help is appreciated. Thank you!
pstglia

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


You are receiving this mail because:
  • You are the assignee for the bug.
--1432130802.5B2dF1A0.7187-- --===============1963437782== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============1963437782==--