Bug 119818

Summary: DRI is not working, cannot load r200_dri.so
Product: [Fedora] Fedora Reporter: Vaclav Cermak <disnel>
Component: xorg-x11Assignee: John Dennis <jdennis>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: jdennis, mharris, mishu
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-04-05 21:19:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 114961    

Description Vaclav Cermak 2004-04-02 12:01:46 UTC
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)

Comment 1 Sammy 2004-04-02 15:08:32 UTC
Same for Radeon VE/7000 

Comment 2 Mike A. Harris 2004-04-03 09:39:17 UTC
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 09:41:41 UTC
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 09:58:54 UTC
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 15:35:42 UTC
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 21:19:00 UTC
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 15:00:19 UTC
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 

Comment 8 Mike A. Harris 2004-04-06 17:36:04 UTC
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.