[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
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 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
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.
-------------- 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