From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040323 Description of problem: DRI is not working. Log from X server looks good, DRI is initialized there. If I try to run some DRI app (glxinfo, for example), it reports that DRI is no available. When I set LIBGL_DEBUG, it reveals, that libGL error: dlopen /usr/X11R6/lib/modules/dri/r200_dri.so failed (/usr/X11R6/lib/modules/dri/r200_dri.so: undefined symbol: EXEC_FREE) libGL error: unable to find driver: r200_dri.so I have ATI Radeon 9200 mobillity card. Version-Release number of selected component (if applicable): xorg-x11-0.0.6.6-0.0.2004_03_11.11 How reproducible: Always Steps to Reproduce: 1. set LIBGL_DEBUG 2. run glxinfo Actual Results: It prints libGL error: dlopen /usr/X11R6/lib/modules/dri/r200_dri.so failed (/usr/X11R6/lib/modules/dri/r200_dri.so: undefined symbol: EXEC_FREE) libGL error: unable to find driver: r200_dri.so to sdterr and says "direct rendering: No" to stdout Expected Results: "direct rendering: Yes" message Additional info: EXEC_FREE is needed for r200_dri.so and radeon_dri.so, so this bug is probably relevant only for radeon users (tried to grep this symbol in all files contained in /usr/X11R6/lib/modules/dri)
Same for Radeon VE/7000
Just off the top of my head, it's possible that the r200 and radeon DRI sources aren't including mem.h. The new libGL PROT_EXEC patch might not have added those includes in the port from 4.3.0, since those files now probably use imports.h but likely used mem.h before. I'll have a quick peek and see if this is the case.
Yep, it appears that that is what the problem is. I'll update the xorg-redhat-libGL-exec-shield-fixes.patch patch for this, and add to next update.
Ok, checked fix into CVS... I'll leave this open for now until the new rpm is built and in rawhide, so that others who experience it might find this bug easier in bugzilla. I'll update the report again once the packages are available also. Thanks for reporting.
Ah, I had fixed this at the end of the day Friday, but had not checked it in pending further testing.
Mike, I just updated the patch. Your solution was correct, we needed to add "include mem.h", the only difference between my version and yours is that I cleaned up the documentation in mem.c, I had noticed some typos and grammatical errors that made it a little hard to read. I did do a "make tag" after submitting the patch to CVS. I'm going to close this now.
Just a probably stupid question: Since this is reported against xorg-x11-0.0.6.6-0.0.2004_03_11.11 and closed with resolution NEXTRELEASE, i expected it to be fixed now (just upgraded to xorg-x11-0.6.6-0.2004_03_30.1), however with that version, glxinfo still reports "direct rendering: No". Is this supposed to be fixed in xorg-x11-0.6.6-0.2004_03_30.1? Thanks -Fritz
As mentioned by John above, it's fixed in internal CVS, and will be in the next build. The bug is marked closed NEXTRELEASE because it will be fixed in the next release, the fixes having been committed to CVS. Once the next build gets into public rawhide, if the problem persists, feel free to reopen the report with fresh details. Thanks for your testing.