Created attachment 38733 [details] patch to Change windowExistsErrorHandler to drawableExistsErrorHandler in glxcmds.c There currently exists a situation in KDE-4.5.X where at certain moments, a current context does not have a valid associated Window, but does have a valid pixmap drawable. If, at such a moment, a call is made to glXDestroyContext() on another no longer needed non-current context, glXDestroyContext() releases pixmap-associated resources that are in use by the current context, resulting in system hangs. A possible patch to remedy this changes BadWindow to BadDrawable in windowExistsErrorHandler of Mesa-7.8.3-rc1.old/src/glx/glxcmds.c (I have also attached the patch; does this make sense?): --- Mesa-7.8.3-rc1.old/src/glx/glxcmds.c 2010-09-16 03:14:45.074000414 -0400 +++ Mesa-7.8.3-rc1.new/src/glx/glxcmds.c 2010-09-16 03:37:43.932000358 -0400 @@ -68,14 +68,14 @@ #if defined(GLX_DIRECT_RENDERING) && !defined(GLX_USE_APPLEGL) -static Bool windowExistsFlag; +static Bool drawableExistsFlag; static int -windowExistsErrorHandler(Display * dpy, XErrorEvent * xerr) +drawableExistsErrorHandler(Display * dpy, XErrorEvent * xerr) { (void) dpy; - if (xerr->error_code == BadWindow) { - windowExistsFlag = GL_FALSE; + if (xerr->error_code == BadDrawable) { + drawableExistsFlag = GL_FALSE; } return 0; } @@ -98,13 +98,13 @@ /* Set no-op error handler so Xlib doesn't bail out if the windows * has alreay been destroyed on the server. */ XSync(dpy, GL_FALSE); - oldXErrorHandler = XSetErrorHandler(windowExistsErrorHandler); + oldXErrorHandler = XSetErrorHandler(drawableExistsErrorHandler); if (__glxHashFirst(sc->drawHash, &draw, (void *) &pdraw) == 1) { do { - windowExistsFlag = GL_TRUE; + drawableExistsFlag = GL_TRUE; XGetWindowAttributes(dpy, draw, &xwa); /* dummy request */ - if (!windowExistsFlag) { + if (!drawableExistsFlag) { /* Destroy the local drawable data, if the drawable no longer exists in the Xserver */ (*pdraw->destroyDrawable) (pdraw);
Created attachment 38759 [details] [review] Patch to fix GarbageCollectDRIDrawables for Pixmaps w/o a Window
Please do look into this bug as it affects a wide range of hardware and a lot of users as is evidenced in the KDE bug report. If more information is required to implement or find the proper resolution, I will try to provide what I can.
The code posted applies to mesa 7.8, but has been removed in 7.9. It would be useful to a) Test if this bug still applies to mesa 7.9 from git (I've been told it applies to a snapshot from 2010/09/09, but haven't been able to reproduce it myself). and if it still occurs, then b) Port the patch to the 7.9 branch & master.
(In reply to comment #3) > The code posted applies to mesa 7.8, but has been removed in 7.9. It would be > useful to > a) Test if this bug still applies to mesa 7.9 from git (I've been told it > applies to a snapshot from 2010/09/09, but haven't been able to reproduce it > myself). > > and if it still occurs, then > b) Port the patch to the 7.9 branch & master. Thanks for looking at this. So, do I understand correctly, that the patch is ok on Mesa-7.8.x ? If this is so, then everyone now using KDE-4.5.x (and presumably Mesa-7.8.x), can use it. I'd love also to test it out on 7.9 -- but I tried several weeks ago and ran into trouble -- I think with the intel driver (xf86-video-intel-2.12.0). I'll try again and get back to you on this. Have you or anyone had a chance to look at BUG #30217 ? thanks again
I just did a build using Intel Corporation 82915G/GV/910GL Integrated Graphics Controller (rev 04) (i915), with xorg-server-1.9.0, xf86-video-2.13.0, libdrm-2.4.22, mesa-7.9-rc2, qt-4.7.0, kde-4.5.1, and linux-2.6.35.7. This is decidedly way downhill (from xorg-server-1.8.2/Mesa-7.8.2) - desktop effects will not even activate anymore. I can force-activate them, but then video is so slow as to be entirely unusable. Perhaps related to a new error message in .xsession-errors: i915_program_error: Exceeded max nr indirect texture lookups (8 out of 4) This is the only error (Xorg.0.log looks good). Summary of some build variations (all using qt-4.7.0, kde-4.5.1., and linux-2.6.35.7): mesa-7.8.2, libdrm-2.4.21, xorg-server-1.8.2, xf86-video-2.12.0 ----> works (with glxcmd.c patch submitted earlier) mesa-7.8.2, libdrm-2.4.22, xorg-server-1.8.2, xf86-video-2.13.0 ----> works (with glxcmd.c patch submitted earlier) mesa-7.8.2, libdrm-2.4.21, xorg-server-1.9.0, xf86-video-2.13.0 ----> cannot start X -- cannot connect to server mesa-7.8.2, libdrm-2.4.22, xorg-server-1.9.0, xf86-video-2.13.0 ----> cannot start X -- cannot connect to server mesa-7.9rc2, libdrm-2.4.22, xorg-server-1.8.2, xf86-video-2.13.0 ----> cannot start X -- cannot connect to server mesa-7.9rc2, libdrm-2.4.22, xorg-server-1.9.0, xf86-video-2.13.0 ----> X runs, but no openGL available under kde (forcing openGL is SLOW: 5 seconds to move a window, plus various artifacts ----> i915_program_error: Exceeded max nr indirect texture lookups (8 out of 4); (src/mesa/drivers/dri/i915/i915_program.c)
Re: comment #3 Testing using Fedora 14 beta, kernel-2.6.35.4-28.fc14 libdrm-2.4.21-3.fc14 mesa-7.9-0.8.fc14 xorg-x11-server-1.9.0-9.fc14 xorg-x11-drv-intel-2.12.0-6.fc14 mesa here is a 20100922 git snapshot. I can confirm the original symptoms remain.
An update with some good news regarding comment #3: I did further testing with the following setup: Intel Corporation 82915G/GV/910GL Integrated Graphics Controller (i915) xorg-server-1.9.0, xf86-video-2.13.0, libdrm-2.4.22, mesa-7.9-rc2, qt-4.7.0 kde-4.5.1, linux-2.6.35.7 As I stated in comment #5, with this build, desktop (GLX) effects will not activate. There's a kde desktop effect called 'blur' which is activated on first kde-desktop boot on my system, but has never worked on my system. Up to now, I've just left it on as it doesn't appear to cause any problems. However, with this new build, 'blur' is in fact the culprit: if I first manually turn off this effect then GLX effects are activated, and the Pixmap destroy issue does not occur. Conclusion: Problem exists in Mesa-7.8.2/3rc1, but has been fixed in Mesa-7.9rc2. The unrelated 'blur' issue, at least for the moment, is kde's problem... thanks for your time.
Closing per comment #7
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.