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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel