All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.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	[thread overview]
Message-ID: <bug-90537-502@http.bugs.freedesktop.org/> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 4133 bytes --]

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.

[-- Attachment #1.2: Type: text/html, Size: 5919 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

             reply	other threads:[~2015-05-20 14:06 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-20 14:06 bugzilla-daemon [this message]
2015-05-20 14:26 ` [Bug 90537] radeonsi bo/va conflict on RADEON_GEM_VA (rscreen->ws->buffer_from_handle returns NULL) bugzilla-daemon
2015-05-20 14:28 ` bugzilla-daemon
2015-05-21  2:12 ` bugzilla-daemon
2015-05-21 19:14 ` bugzilla-daemon
2015-05-21 19:19 ` bugzilla-daemon
2015-05-21 20:09 ` bugzilla-daemon
2015-05-22  8:53 ` bugzilla-daemon
2015-05-22  9:30 ` bugzilla-daemon
2015-05-22 11:49 ` bugzilla-daemon
2015-05-22 12:07 ` bugzilla-daemon
2015-05-22 12:16 ` bugzilla-daemon
2015-05-23  1:22 ` bugzilla-daemon
2015-05-24 14:25 ` bugzilla-daemon
2015-05-24 14:26 ` bugzilla-daemon
2015-05-24 14:29 ` bugzilla-daemon
2015-05-25 12:10 ` bugzilla-daemon
2015-05-25 16:32 ` bugzilla-daemon
2015-05-26  8:12 ` bugzilla-daemon
2015-05-26  9:06 ` bugzilla-daemon
2015-05-26  9:06 ` bugzilla-daemon
2015-05-26  9:30 ` bugzilla-daemon
2015-05-26 16:16 ` bugzilla-daemon
2015-05-26 18:09 ` bugzilla-daemon
2015-05-26 18:12 ` bugzilla-daemon
2015-05-27 10:00 ` bugzilla-daemon
2015-06-25  2:46 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-90537-502@http.bugs.freedesktop.org/ \
    --to=bugzilla-daemon@freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.