Bug 3956

Summary:	Crash in DRI programs: "User called no-op dispatch function (an unsupported extension function?)"
Product:	Mesa	Reporter:	Ignacio <ignaciovicario>
Component:	Drivers/DRI/Mach64	Assignee:	Default DRI bug account <dri-devel>
Status:	RESOLVED FIXED	QA Contact:
Severity:	critical
Priority:	high
Version:	unspecified
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Ignacio 2005-08-03 06:47:08 UTC

When trying to play the game gl-117 and after setting LIBGL_DEBUG=verbose I 
get this in the console: 
 
Info: Found gl-117 data directory /usr/share/games/gl-117 
Info: Startup gl-117, V1.3 ... 
Info: Loading /home/durr/.gl-117/conf 
Info: Saving /home/durr/.gl-117/conf 
Info: Loading /home/durr/.gl-117/conf.interface 
Info: Saving /home/durr/.gl-117/conf.interface 
Info: Using SDL and GLUT 
libGL: XF86DRIGetClientDriverName: 6.5.6 mach64 (screen 0) 
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/mach64_dri.so 
drmOpenByBusid: Searching for BusID pci:0000:01:00.0 
drmOpenDevice: node name is /dev/dri/card0 
drmOpenDevice: open result is 6, (OK) 
drmOpenByBusid: drmOpenMinor returns 6 
drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 
Info: Using SDL_mixer 
Info: No joystick found 
Mesa 6.3.1 implementation error: User called no-op dispatch function (an 
unsupported extension function?) 
Please report at bugzilla.freedesktop.org 
 
(error message repeated many times) 
 
Also, glxgears crashes with "Segmentation fault" 
 
I have an ATI Rage Mobility-M AGP 2X (Mach64 chipset). DRI, Mesa and  DRM was 
compilled following http://dri.freedesktop.org/wiki/Building. 
 
On earlier buildings I had no problems with DRI. 
 
The problem may be partially solved in this way: 
 
After install xorg, and before install Mesa, I made a copy the  
file /usr/X11R6/lib/modules/dri/mach64_dri.so to a temporary folder. This  
file was isntalled when I installed xorg, and would be overwritten when  
installing Mesa. After fimishing the whole compile-install procedure, I copied 
the file mach64_dri.so made by xorg, which I had put  before  
in a temporary folder, to /usr/X11R6/lib/modules/dri/ overwriting the one  
installed when installing Mesa. The result  was that I got again direct  
rendering. Great, by with lower speed than with earlier compilations of CVS  
(but higher than with indirect rendering).  
 
The DRI release where I got this is: 
 
X Window System Version 6.8.99.900 (6.9.0 RC 0) (Minimal DRI build from X.org 
tree) 
Release Date: 01 August 2005 + cvs 
X Protocol Version 11, Revision 0, Release 6.8.99.900

Comment 1 Ian Romanick 2005-08-06 04:49:42 UTC

This should be fixed by recent (less than an hour ago) commits.  Could you
please re-test with current CVS?

Comment 2 Ignacio 2005-08-07 01:36:06 UTC

(In reply to comment #1) 
> This should be fixed by recent (less than an hour ago) commits.  Could you 
> please re-test with current CVS? 
 
I have updated to last CVS and the problem is the same: mach64_dri.so made by 
Mesa does not work. There is a similar problem with unichrome: 
http://sourceforge.net/mailarchive/forum.php?thread_id=7886004&forum_id=6511. 
And Mesa driver for i915 also fails with symptoms similar to the ones I  had 
before: 
http://sourceforge.net/mailarchive/forum.php?thread_id=7882216&forum_id=6511 
 
Anyway, right now, if I set "#define DriDrivers mach64" in host.def, when 
installing xorg it installs a /usr/X11R6/lib/modules/dri/mach64_dri.so which 
looks to work fine and with the same speed I had before this problem (previous 
trials with this approach gave me lower speed). 
 
Now, for me, the question is, would mach64_dri.so from Mesa have better 
performance than the one compiled from the xc folder? if the answer is "no", 
at least in my system compilation and install of Mesa driver would be 
unnecessary. 
 
If you want me to test anything more, please, tell me.

Comment 3 Ignacio 2005-11-09 15:43:46 UTC

In latest CVS versions, mach64_dri.so compiled from Mesa works fine again.

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.