http://bugs.freedesktop.org/show_bug.cgi?id=10561
------- Comment #6 from [EMAIL PROTECTED] 2007-04-08 12:19 PST -------
Since gdb is unworkable, I chose another route
and analyzed strace output.
It's pretty clear what's going on:
futex(0x9b29a38, FUTEX_WAKE, 2147483647) = 0
ioctl(13, 0x4008642a, 0xffeda0b4) = 0
ioctl(13, 0x40106450, 0xffed9a8c) = 0
ioctl(13, 0xc018644e, 0xffed9a90) = -1 EAGAIN (Resource temporarily
unavailable)
nanosleep({0, 1000}, NULL) = 0
[last two lines repeated 4ever]
Decoding the ioctl numbers (wonder why strace doesn't do it already)
leads us to this:
- 2a -> DRM_IOCTL_LOCK
- 50 -> DRM_RADEON_CMDBUF
- 4e -> DRM_RADEON_TEXTURE
I checked and all sizes match the expected structures (32bit versions).
So we should end up in radeon_ioc32.c:compat_radeon_cp_texture(),
then radeon_cp_texture(), and finally radeon_cp_dispatch_texture(),
where the fun starts.
The return code of EAGAIN most probably comes from here:
buf = radeon_freelist_get(dev);
[...]
if (!buf) {
DRM_DEBUG("radeon_cp_dispatch_texture: EAGAIN\n");
if (DRM_COPY_TO_USER(tex->image, image, sizeof(*image)))
return DRM_ERR(EFAULT);
return DRM_ERR(EAGAIN);
}
Now the question is: how's can radeon_freelist() return NULL?
And another good question is: why does the client need to
retry allocating a texture in an infinite polling loop?
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--
_______________________________________________
Dri-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel