Bug 119818 - DRI is not working, cannot load r200_dri.so
DRI is not working, cannot load r200_dri.so
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: John Dennis
Depends On:
Blocks: FC2Blocker
  Show dependency treegraph
Reported: 2004-04-02 07:01 EST by Vaclav Cermak
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-04-05 17:19:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Vaclav Cermak 2004-04-02 07:01:46 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2)

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

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):

How reproducible:

Steps to Reproduce:
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)
Comment 1 Sammy 2004-04-02 10:08:32 EST
Same for Radeon VE/7000 
Comment 2 Mike A. Harris 2004-04-03 04:39:17 EST
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.
Comment 3 Mike A. Harris 2004-04-03 04:41:41 EST
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.
Comment 4 Mike A. Harris 2004-04-03 04:58:54 EST
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.
Comment 5 John Dennis 2004-04-05 11:35:42 EDT
Ah, I had fixed this at the end of the day Friday, but had not checked
it in pending further testing.
Comment 6 John Dennis 2004-04-05 17:19:00 EDT
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. 
Comment 7 Fritz Elfert 2004-04-06 11:00:19 EDT
Just a probably stupid question: 
Since this is reported against xorg-x11- 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? 
Comment 8 Mike A. Harris 2004-04-06 13:36:04 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.