During install, Workstation configuration was chosen and all package groups 
were selected (GNOME, KDE, Development, and Entertainment).

Attach your X server log and configuration file(s) using the link below.

In response to your request, I regret to tell you that I had to revert the 
system back to RHL 7.1. This particular system is used heavily and cannot be 
kept in a hung state to analyze such a problem. Given that, I can at least 
share my observations regarding the behavior of the X server as I made futile 
attempts to figure out what might be wrong.

After the clean install, the console (text) login prompt was present. So I 
logged in as root and tried starting the X server manually via the "startx" 
command. This resulted in some error messages that were somewhat confusing. For 
instance, the program complained that the "LeftAlt" keyword (and others in that 
section of the XF86Config file) were not recognized. In a probing effort, I 
commented-out lines with cited keywords and noticed that it was complaining 
about things I was sure were valid (at least they were in 7.1). For instance, 
another item it cited was the lack of a "Device" specified in the "Driver" 
sections.

Comparing my mental image of the 7.3 X config file with what is currently in my 
7.1 installation, they appear identical to me. All those keywords startx 
complained about are there and apparently correct.

Sorry I could not provide the X server log file. If you have something you'd 
like for me to try and you feel confident it may resolve this problem, I may be 
willing to attempt the 7.3 install again.

One thing I did not mention in my original post is that the message in the 
Summary section of this bug description appeared about every 5 minutes (maybe 
slightly longer). I guess I figured that would have been pretty obvious.

Correction to last post. The passage

"For instance, another item it cited was the lack of a "Device" specified in 
the "Driver" sections."

should have read

"For instance, another item it cited was the lack of a "Driver" specified in 
the "Device" sections.

While I appreciate your efforts of reporting this bug, Red Hat does
not have every piece of video hardware and motherboard available with
which to troubleshoot problems that are reported.  As such, with most
XFree86 bug reports, we often require the user having the problem to
test various things and provide various log files, config files, and
results of other tests back to us while we try to troubleshoot the
problem.

It sounds like this is a production system which you are not able
to provide the time/energy to aide in troubleshooting.  This is
unfortunate because without access to such a system, there is nothing
we can do to resolve the issue, unless someone having the problem
is willing and able to troubleshoot it.

If you can at least provide the output of "lspci -v" and also "lspci -vn"
from the system in question, I will see about changing the default
driver options or change drivers.

Thanks.

I agree and I most definitely wish I could do more. Perhaps I can acquire 
another hard drive from our IS department and try the install again to get the 
information you request. The main problem(s) with that will be A) I work on 
contract and there is no funding for me to do this sort of research, B) our IS 
department may not have a spare hard drive, C) I simply may not have the time 
(the installation takes about 45 minutes on this rather old/slow system). As 
it stands, RHL 7.1 is and has been performing fine for me since it was first 
installed. My only reason for upgrading in the first place was that I like to 
keep my software development systems as current as possible. Again, I will see 
what I can do, but no promises.

Regards,
Bruce Scherzinger

Please try manually selecting the "vesa" driver instead.  Or try our
new release when it comes out, as it should work correctly.  Our current
beta release should also work correctly for this card, by choosing the
"vesa" driver.

FIX

The 7.3 installation program ERRONEOUSLY symlinked /usr/X11R6/bin/X to /usr/X11R6/bin/XFree86 (the 4.2.0 version of the X server).

It should have instead symlinked /usr/X11R6/bin/X to /usr/X11R6/bin/XF86_S3 (the 3.3.6 version of the X server, which the installation program did 
correctly install for the older S3 Trio64 video card).

People with older video cards should be warned of this problem with the 7.3 upgrade.

Thanks to Thomas Dodd, Michael Fratoni, and David Wood for their ID and fix to this bug (in their earlier posts on valhalla-list).

Regards, Neil

An additional comment that may be of further help:

Upon the relink of the X symlink (to XF86_S3), startx comes up as expected.  IF you're logged in as "root".

When non-root, startx (on the XF86_S3 server) fails, due to the file permissions settings on XF86_S3.

One fix (somewhat scary however, as it opens up a security hole with the X server), is to set SUID on the XF86_S3 file, via:
# chmod 4711 XF86_S3

Hope this helps.

btw... does anyone know of a safer way to set the permissions for this?  Thanks in advance.

Regards, Neil