Bug 24231 - X server (4.0.2-1) dies shortly after starting Q3A skirmish
X server (4.0.2-1) dies shortly after starting Q3A skirmish
Status: CLOSED DEFERRED
Product: Red Hat Raw Hide
Classification: Retired
Component: Mesa (Show other bugs)
1.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-17 13:53 EST by Bill Crawford
Modified: 2007-04-18 12:30 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-01-26 12:04:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bill Crawford 2001-01-17 13:53:55 EST
Shortly after attempting to start a skirmish game in Q3A, in fact almost
anything, the X server dies and returns me to the command line.  There is
an error that reads something like "detected attempt to write across stack
boundary".  Doesn't happen if I use the libGL.so.1.2 from the XFree86 build
tree.

Bit of an impedance mismatch between the two?
Comment 1 Bernhard Rosenkraenzer 2001-01-18 17:37:32 EST
Are you seeing the same problems in any other applications? I don't have 
Q3A to reproduce this (and we generally can't support proprietary software 
like Q3A, it's virtually impossible to debug).

Comment 2 Bill Crawford 2001-01-18 18:25:29 EST
No, but it doesn't happen with the version from the XFree86 build tree, so I'm
considering this a side-effect of Red Hat's choice to maintain a separate Mesa
package.

You could use the libGL.so from XFree86 and just build libOSMesa from the
standalone Mesa sources. As of last week libGLU is in the XFree86 tree as well,
so the separate Mesa package is looking less useful all the time.

By all means rip the GL stuff out of the X tree and package it separately :)
Comment 3 Bernhard Rosenkraenzer 2001-01-18 18:29:06 EST
The package is definitely necessary and must be called libGL: The XFree86 libGL
doesn't do software rendering (it works only on cards supported by DRI) and
doesn't work with XFree86 3.3.6 (yes, there are still cards that work only with
3.3.x).
Comment 4 Bill Crawford 2001-01-18 18:44:51 EST
The one I'm using happily falls back to software rendering when I chmod
/dev/dri/card0 to prevent access ... and plenty of people have problems actually
enabling DRI when they have got the right library :)

Seriously, this is a pain ... and it's only seasoned people who can read the
docs and have the opportunity to rebuild stuff from source who fix it.

Hack a version together that does work with 3.3.6 (is there any way to hack both
Utah-GLX and DRI support in ?)
Comment 5 Bill Crawford 2001-01-21 16:20:38 EST
I'm toying with making the GL stuff from XFree86 into a separate XFree86-GL or
-DRI package, which could be installed instead of Mesa for those who would
benefit from it. Would you consider this an option ?
Comment 6 Sammy 2001-01-22 10:51:39 EST
Yes....other people can benefit from this too, like myself. I use the
NVIDIA GL drivers and everytime I update XFree I need to go and delete
all the GL files from it since they conflict with nvidia's stuff.
Comment 7 Bill Crawford 2001-01-22 20:13:09 EST
Uh, no ... currently the GL stuff from XFree86 is NOT included in the Red Hat
packages. I'm suggesting they DO include it, but split out into a separate
package that can be installed instead of Mesa.
Comment 8 Sammy 2001-01-26 11:22:12 EST
Well, how about the files /usr/X11R6/lib/modules/extensions/libglx.a and
libGLcore.a  or .so in the same directory? They are in the XFree86 rpms
and according to Nvidia I am supposed to delete them (in addition to Mesa
stuff of course).
Comment 9 Bill Crawford 2001-01-26 12:04:43 EST
That's nVidia's problem, not Red Hat's problem.  nVidia chose to bypass the
mechanisms built into XFree86-4.x and develop their own (direct?) rendering
infrastructure, and so cannot cohabit with the XFree86 version.  This also,
presumably, makes it difficult to support both an nVidia chipset and any other
card using the same server ...

AFAIK, those files are not part of Mesa either.

That said, it might well be a good idea to package those particular files
together with the libGL library.
Comment 10 Bernhard Rosenkraenzer 2001-05-21 15:48:18 EDT
The problem is that we need software rendering even for cards not supported by 
XFree86 4.0.x at all (using XFree86 3.3.x servers), so using the XFree86 libGL 
is not an option ATM.

This will be fixed in XFree86 4.2.0 though (they're adapting the patch).

Comment 11 Bill Crawford 2001-05-21 20:10:02 EDT
OK, I finally got my head around this (in part by reading an exchange between
Mike and the DRI-Devel mailing list :o)
The most recent XFree86/Mesa combination I tried did actually work, although it
wasn't completely stable; the instability is basically fixed now in the DRI &
XFree86 CVS trees by a completely new version of the DRI/DRM.  So this is no
longer a problem, basically.
My apologies to Mike and Bernard for the complaints.

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