Commit 29598e5253ff5c085ccf63580fd24b84db848424 causes a hard lock when a GL program is finishing, including glxinfo and glxgears. The program causes a hard lock somewhere in the DRM clean up code, just before it would normally terminate. I'm using GNU/Linux (kernel 2.6.18-rc7) with DRM and libdrm from the Freedesktop Git repository, and Mesa3d from CVS. Hardware is x86_64 and r300. Here is the git bisect log, which might be reformatted slightly by Bugzilla: 29598e5253ff5c085ccf63580fd24b84db848424 is first bad commit commit 29598e5253ff5c085ccf63580fd24b84db848424 Author: Michel Dänzer <michel@tungstengraphics.com> Date: Tue Aug 22 16:40:07 2006 +0200 Add support for tracking drawable information to core Actually make the existing ioctls for adding and removing drawables do something useful, and add another ioctl for the X server to update drawable information. The only kind of drawable information tracked so far is cliprects. :040000 040000 9c46f2929e7e467e89f2c3861e17ae2f2eaf3093 b27b1f454d9d5ed68b3459d04c959a04c6e98532 M bsd-core :040000 040000 875ea5d4e5a1295b49b2b9cbad8e4bec4b5f4f66 dcbd1623cfe3e09455b7d18e28b3a9cc3627da77 M libdrm :040000 040000 1884fe493d0109d428c564bd8c851376d58bdf82 7971362b40e3a9be1e56f8521f797e0730337276 M linux-core :040000 040000 190e4b4b9dc21ad45a0e4a16a4a44f21e0ca7367 ba516c2516c4d46fa98e18c695c51c64f9e2c59d M shared-core
First of all, the first couple of drawable info commits definitely had issues, make sure you have all commits touching drm_drawable.c. If it still happens then, maybe 'hard lock' just means the X server dies due to an oops in the DRM? Can you log in remotely and attach any relevant kernel output?
I get the hard lock even with the latest DRM, after all of your patches have been committed. I don't think it's just the X server dying, but it seems to be somewhere in the DRM kernel code. I'll attach the kernel log.
Created attachment 7216 [details] Kernel log
Created attachment 7217 [details] [review] Check destination pointers for memcpy Well, it does seem to happen in drm_rmdraw(), as I suspected. Does this patch help? If not, can you try narrowing it down by adding debugging output to drm_rmdraw()?
No, that patch didn't help. :( But I found out that it's not an actual hard lock in the kernel, but just the X server dying, as you suggested. It just seemed like a hard lock since the monitor wouldn't update even when switching to a text virtual console.
Felix Kühling spotted the problem, should be fixed in d58389968124191a546a14b42ef84edc224be23d. Please reopen if you still have this issue with that.
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.