Bug 36158

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.

Created attachment 15524 [details]
X log file of crash

Created attachment 15525 [details]
X configuration file

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.

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

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

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

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]

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.

*** Bug 36996 has been marked as a duplicate of this bug. ***

Changing summary to better reflect problem.

*** Bug 38869 has been marked as a duplicate of this bug. ***

*** Bug 38648 has been marked as a duplicate of this bug. ***

I think I found a solution to this.  I had the same "radiating lines" deal that 
clytle374 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.

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

Confirmed, that http://dri.sourceforge.net/res/voodoo5/x86/libglide3.so solves the problem.

I have followed alane 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...

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...

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.