This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 36158 - (Voodoo 4/5) wrong Glide library + Glide problem.
(Voodoo 4/5) wrong Glide library + Glide problem.
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
: 36996 38648 38869 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-04-17 01:42 EDT by James Brents
Modified: 2007-04-18 12:32 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-06-05 11:37:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
X log file of crash (11.03 KB, text/plain)
2001-04-17 10:35 EDT, James Brents
no flags Details
X configuration file (1.33 KB, text/plain)
2001-04-17 10:36 EDT, James Brents
no flags Details

  None (edit)
Description James Brents 2001-04-17 01:42:04 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.8.1+)
Gecko/20010416


First I was using xine, however xine will not work with the Xv module,
giving the following error:
Hmph - XvShmCreateImage returned a zero size - probably best to try again
without Xv

Then Mesa-demos applications were run, ALL produced the following error:
gd error (glide): gd error (glide): grSstSelect:  non-existent SSTgd error
(glide): grSstSelect:  non-existent SSTSegmentation fault (core dumped)

So then a quick view of the core shows:
#0  0x40855bf1 in grSstWinOpen () from /usr/lib/libglide3.so.3
#1  0x40869569 in _grMipMapSize () from /usr/lib/libglide3.so.3
#2  0x406b973c in XMesaMakeCurrent ()
   from /usr/X11R6/lib/modules/dri/tdfx_dri.so
#3  0x405b0f7f in driMesaBindContext ()
   from /usr/X11R6/lib/modules/dri/tdfx_dri.so
#4  0x401f2469 in xf86DRIMakeCurrent () at eval.c:41
#5  0x46932008 in ?? ()

Both use XFree86-libs, and has worked in the past. Hardware: 3dfx Voodoo4
4500 AGP
Additionally, when using KDE, when selecting a screen saver that had GL
next to it, caused KDE to lock, and be unreponsive, unable to change VC's,
and could not kill it from another machine, had to reboot.
Also Quake3 causes some interesting problems - it simply locks up, and I
must login from another machine to kill it - can not change VC's to kill
it. Of course I've only been using 7.1 for about 8 hours now, but this all
seems very wrong. Both problems did not exist when using 7.0.

Im of course more than welling to test/assist in any way.

Reproducible: Always
Steps to Reproduce:
Use any thing that seems to use Glide or OpenGL.
Comment 1 Mike A. Harris 2001-04-17 08:07:58 EDT
Please - one bug per bug report.  If there are multiple bugs in one report
when the first one gets fixed, the bug gets closed, and the others are lost.

Xine does not ship with the distribution.  If you have trouble with it,
get the source code and rebuild it.  If it wasn't built against seawolf
it *wont* work because Seawolf is the first Red Hat Linux release to
include shared libraries for Xv and Xxf86dga.  My xine works - built
against seawolf.

Make *sure* if you're using a 3dfx card that it is in 16bit color depth or
it will crash.  The tdfx driver only supports 16bpp with 3D acceleration.

If you still have problems after these suggestions, please attach your config
file XF86Config-4 and your X server log from after a crash occurs, but *before*
you start up X again.  If you boot into the GUI (runlevel 5), boot to runlevel
3 instead and run X with "startx" to capture the logs.

Attach these files using the file attachment link in bugzilla directly below.
Comment 2 James Brents 2001-04-17 10:35:39 EDT
Created attachment 15524 [details]
X log file of crash
Comment 3 James Brents 2001-04-17 10:36:47 EDT
Created attachment 15525 [details]
X configuration file
Comment 4 James Brents 2001-04-17 10:42:05 EDT
The only way I can make it crash hard is by going to the KDE screen savers and
selecting "Space (GL)" all other actions dont result in a crash thats not easy
to fix, so thats the action I did when logging.

I compiled xine from scratch on 7.1 but still receive the same error. And I have
also been using a 16 bit color depth.
Comment 5 James Brents 2001-04-17 16:17:33 EDT
Also related, glxinfo reports
gd error (glide): gd error (glide): grSstSelect:  non-existent SSTgd error
(glide): grSstSelect:  non-existent SSTSegmentation fault (core dumped)

xvinfo reports:
  Adaptor #1: "3dfx Accelerated Video Engine"
    number of ports: 1
    port base: 75
    operations supported: PutImage 
    supported visuals:
      depth 16, visualID 0x23
      depth 16, visualID 0x24
      depth 16, visualID 0x25
      depth 16, visualID 0x26
      depth 16, visualID 0x27
      depth 16, visualID 0x28
      depth 16, visualID 0x29
      depth 16, visualID 0x2a
      depth 16, visualID 0x2b
      depth 16, visualID 0x2c
      depth 16, visualID 0x2d
      depth 16, visualID 0x2e
      depth 16, visualID 0x2f
      depth 16, visualID 0x30
      depth 16, visualID 0x31
      depth 16, visualID 0x32
    no port attributes defined
    maximum XvImage size: 1024 x 0
    Number of image formats: 0
Comment 6 Mike A. Harris 2001-04-25 14:51:00 EDT
You have errors in your configuration somewhere.  Look at the log near the
bottom and you can see XSetFontPath foobing.  Check your font server config
for errors.

Other points to note:
(WW) TDFX(0): Failed to set up write-combining range (0xe0000000,0x4000000)

xrdb: colon missing on line 557, ignoring line

Bad line in your .Xresources or something that is being read by xrdb?

Are you using a homemade kernel?  Please supply the results of:
uname -a
cat /proc/mtrr
cat /proc/cpuinfo

Comment 7 James Brents 2001-04-25 15:34:02 EDT
Just stumbled on this, Commenting out the line
#Load  "dri"            # Direct rendering infrastructure
from my XF86Config-4 file causes glxinfo and the Mesa demos to work
However this does not fix xine from not being able to use Xv
I do not have a .Xresources file, nor have I modified any system wide settings..
Here is the additional info you requested.

[syonic@Mars syonic]$ uname -a
Linux Mars.nistix.com 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknown
[syonic@Mars syonic]$ cat /proc/cpuinfo
processor
: 0
vendor_id
: AuthenticAMD
cpu family	: 6
model
	: 4
model name	: AMD Athlon(tm) Processor
stepping
: 2
cpu MHz		: 900.059
cache size	: 256 KB
fdiv_bug
: no
hlt_bug
	: no
f00f_bug
: no
coma_bug
: no
fpu
	: yes
fpu_exception
: yes
cpuid level	: 1
wp
	: yes
flags
	: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr
syscall mmxext 3dnowext 3dnow
bogomips
: 1795.68

[syonic@Mars syonic]$ cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size=16711936MB: write-back, count=1
reg05: base=0xe8000000 (3712MB), size=16711744MB: write-combining, count=1

Ive used homemade kernels as well, with mtrr and DRI drivers enabled, they also
do not work.

Font server config has not been modified in any way
Comment 8 j. alan eldridge 2001-04-26 02:19:51 EDT
I think I've got a handle on this. I've got Voodoo5 AGP 5500. Same symptoms. 
Anything that uses Mesa, which uses glide, locks up X nice and solid.

Hello? The symlink to the shared library is *wrong*.

/usr/lib/libglide.so.3.10.0 ==> glide3/libglide3-v3.so. 

Look at /usr/lib/glide3: you've got libglide3-v3.so and libglide3-v5.so. A 
Voodoo5 needs the latter (a Voodoo4 probably does also; the web material I had 
linked is no more so I can't check right now).

Now here's the neat part: during anaconda, when the X server setup is checking 
hardware, it *knows* if you've got a Voodoo3 or a 4 or 5. WTF doesn't it save 
that info, so when it makes the symlink for X later, it can also symlink the 
glide libs appropriately?? 

I guess with the death of 3dfx this will all be academic in a couple of 
releases, since it's ATI or Nvidia. Which is the lesser evil? [sigh]

Comment 9 cory lytle 2001-04-26 04:57:14 EDT
I am having the same problem, gl locks up machine and glxinfo gives above error
ending in a core dump.
I just tried the link fix from the above post, glxinfo now works and reports
direct rendering.
Now the screen is only a group of line radiating from the lower left corner of
the screen.

Will be glad to help in any way.

Comment 10 Mike A. Harris 2001-05-04 03:43:31 EDT
*** Bug 36996 has been marked as a duplicate of this bug. ***
Comment 11 Mike A. Harris 2001-05-04 03:46:06 EDT
Changing summary to better reflect problem.
Comment 12 Mike A. Harris 2001-05-04 03:49:43 EDT
*** Bug 38869 has been marked as a duplicate of this bug. ***
Comment 13 Mike A. Harris 2001-05-04 03:52:23 EDT
*** Bug 38648 has been marked as a duplicate of this bug. ***
Comment 14 Need Real Name 2001-05-08 18:34:14 EDT
I think I found a solution to this.  I had the same "radiating lines" deal that 
clytle374@yahoo.com had.  Here's what I did to fix it:

1. Download http://dri.sourceforge.net/res/voodoo5/x86/libglide3.so
2. Copy libglide3.so to /usr/lib/glide3/
3. Remove /usr/lib/libglide3.so.3.10.0 (or rename it if you're unsure)
4. Recreate /usr/lib/libglide3.so.3.10.0 as a symlink to
/usr/lib/glide3/libglide3.so

This is using a "stock" RH 7.1 install on a AMD 1.33GHz Athlon, Asus A7M266
mainboard and a Voodoo5 5500 AGP card.  The only hitch is that Tribes2 doesn't
seem to display.  But since Tuxracer, Heavy Gear II, the xscreensaver GL stuff,
etc all work, I think the T2 problem is endemic to T2.  So this "fix" ought to
work.

IMHO, RH ought to add something on their errata (or package enhacement) page
about this.  I had to dig around for about two days before stumbling on the
driver issue.  I should think a simple RPM update with the new Glide driver
ought to do the trick.
Comment 15 Charles R. Tersteeg 2001-05-08 20:01:05 EDT
using a nightly tdfx driver and GL and GLU libraries, I'm playing tribes2.  My
vehicle frame rate sucks at 16bit 800x600, got me.  Other wise UT and other
openGL programs seem okay.

I'd like to see a rpm fix for too as, I have a few friends interested in rh7.1,
but if no voodoo workie for games, they are not that interested in using it.

my 2 cents
chuck
Comment 16 Harald Hoyer 2001-05-14 06:23:44 EDT
Confirmed, that http://dri.sourceforge.net/res/voodoo5/x86/libglide3.so solves the problem.
Comment 17 iceman 2001-05-14 12:01:49 EDT
I have followed alane@geeksrus.net advise by fixing the link to be

/usr/lib/libglide.so.3.10.0 ==> glide3/libglide3-v5.so. 

and the problem dissapeared. No more errors.

Thank you...
Comment 18 James Brents 2001-06-05 11:36:57 EDT
Are there any plans on releasing an official update to the affected packages?
There are alot of people with Voodoo4/5 cards, so at least I feel this is
warranted. Its only been nearly 2 months since the report...
Comment 19 Mike A. Harris 2001-07-16 04:33:59 EDT
No.  The problem is fixed easily by updating the symlink manually.  While
that may be inconvenient, it does not warrant the release of an XFree86
errata.  XFree86 is huge, and it takes a very large reason for an errata
release.  There will be one at some point, but not because of a minor
inconvenience.

The root of this problem is that Glide is just a braindead thing in the first
place.  Semi-Ultimately there should be only ONE Glide library and that
library should detect which card is in use and special case things like
common sense dictates.  That would have been the wise way for Glide to
have been implemented in the first place.  Even more ultimately though
would be if Glide did not exist at all, and 3dfx had implemented drivers
using the standard OpenGL library API at the time.  Their legacy of Glide
is why support for 3dfx sucks and is pretty much idle right now.

That is the negative part... The good part?  The good part is that this
problem bothered me so I did some begging here and there and the result of
that begging is that the current developmental branch of Mesa now includes
code to load the appropriate glide lib at runtime from internally.

This will make the problem go away and 3dfx users need not worry about the
library symlink in the future.  I have hacked up a possible temporary solution
in rawhide for now in the 4.1.0-0.9.1 release.  The real solution (above) might
appear in the XFree86 4.2.0 release sometime later this year perhaps.

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