Try my updated XFree86 with many many Voodoo 3 and other 3dfx fixes, it should
work way better for you.  Version 4.0.3-15

ftp://people.redhat.com/mharris/testing

It works fine for me, how about you?

I tried the version you gave me, but the problem stays..nothing changed.

I also have a Voodoo 3 card and I've been monitoring this bug hoping to see a 
resolution.  What is the current status of this problem?  I haven't seen 
anything happening for a while.

I get this problem but only when a game tries to go into full screen mode.  It
puts the mouse cursor in the top left corner and then after a couple of seconds
proceeds to reboot X.  All consoles have an image of the X desktop on them and
the X server actually moves around.  I usually have it on VC2 and after a crash
it will have moved to VC3.  When X recrashes, the server moves back to VC2.

X continues to work ok, but I have to reboot to get back to my consoles.

I have tried all versions of X from rawhide and they all do the same thing.

I have problems with voodoo3 and RH 7.1 too. With RH 7.0 it worked well; now at
startup there are strange pixels here and there and eventually it locks up. Had
to revert to 3.3.6.
I searched in ftp://people.redhat.com/mharris/testing with no luck...
I downloaded 4.1 from rawhide, but I had to install too much things to make it
works; i'd prefere a patch against RH7.1...

I have found that for a temporary fix, your can can change the X configuartion 
file so that it only has 1 resolution to change to.  Annoying as this is, this 
is the only thing that works for me at the moment.

I tried it. Simply it crashes a bit later, after I move a bit the windows. It
begins to fill the screen with red and green dots and the locks. I have just one
resolution (1280x1024x24) on the 
configuration, but my voodoo3 does not work. I tried to select 32 bit/pixel, but
the driver say it cannot do it. 

I only have a problem when I attempt to change resolutions.  Otherwise my 
Voodoo 3 works fine with XFree86 4.0.3.  I would like to get this problem 
fixed since there are many times when I would like to change resolutions.  
Right now what I do is change configuration files to a configuration with the 
resolution I want and restart X.  All of the resolutions I am using are 16 bit 
not 24 bit.  I noticed that romano is trying 1280x1024x24.  I am using 
1280x1024x16.  Maybe if you change to 16 bit it will work.

You cannot do DRI on a Voodoo 3 in anything other than 16 bit depth.
This is a hardware limitation, not an X limitation.  Also, you cannot
use 1280 as that is way too high resolution for a 16Mb card to use
with DRI.  3D accel requires gobs of RAM and can't get it if it is
used for a large double buffered 2D framebuffer.

Solution:  Depth 16, resolution 800x600, *maybe* 1024x768 tops.
If you must use 1280, you'll have to either not use DRI, or get a
card with more memory.

This does not make any sense. I indeed am using 1280x1024 with this 16MB card.
And I am aware of the hardware limitation of 16 bit depth so I run it in 16 bit.
But before I started using Redhat 7.1. I was using Debian woody with the same X
version as is included with Redhat 7.1 and I never had any problems alike the
one I described here. 

I think this solution is a bit too easy. I won't reopen the bug for now, but I
would appreciate a reaction.

Why is the status of this problem listed as CLOSED and the resolution NOTABUG. 
 I haven't seen any resolution to this problem other than don't change 
resolutions, which in my opinion is a copout.  There is definitely a problem 
here.  You can't change resolutions in XFree86 with Version 4.03 on RedHat 
7.1.  The solution that mharris suggested of moving to XFree86 V4.1 apparently 
did not work according to roevens.  I was waiting for further comments from 
mharris or roevens before I attempted to move to XFree86 V4.1 especially since 
roevens reported that it didn't fix his problem.  How can this whole problem 
be closed?

The XFree version mharris suggested was an updated version of the 4.0.3 version
with alot of Voodoo3 and other fixes. Not 4.1. Maybe it is solved with 4.1, I
don't know, and RedHat doesn't provide a 4.1 version for 7.1 (yet?), and I don't
have time to use the rawhide's 4.1 since it needs alot of libs to be updated
according to romano.
Meanwhile I tried Mandrake 8, and it has exactly the same problem.. But isn't
Mandrake based on RedHat? I don't know anymore.. But I'm sure that I didn't have
any problems with the previous X versions in the previous Redhat releases. I was
running exact the same resolution: 1280x1024x16, DRI was loaded and working
(Quake 3, Xscreensavers, Mesademo's .. , it all worked). Then I used Debian for
a while with XF 4.0.3 and it didn't have the bug either. It only came up with
RedHat 7.1 and Mandrake 8. 
I, like others among us, do not agree with the closed bugstatus. And as you can
read in my previous comment, I don't reopen the bug for now, but I want a better
solution than running in a resolution of 800x600. It worked before in 1280x1024,
so it has to work now

Strictly speaking 1280x1024x16 is working for me.  I just can't change the 
resolution on the fly.  Exactly the problem that roevens reported.  If I want 
to change the resolution then I have to use a new X configuration file and 
restart the X server.  Does changing the resolution work if you use 800x600 or 
below?

Does this problem occur with DRI *DISABLED*?
Please attach your config file and X server log from after a crash
(do not use xdm/kdm/gdm), using the link below.  Set your machine
in 800x600x16 for this test, and include whatever lower resolutions
you like.  If DRI is disabled, use whatever resolution you like.
I need to know if this occurs with and without DRI.

Also... I should note that 4.0.3 is now officially obsolete, so
any bug fixes in XFree86 releases will be in 4.1.0 or later.  I
will not be releasing any further 4.0.3 packages officially or
unnofficially.  The latest is 4.0.3-24.
There will be a 4.1.0 errata for 7.1 at some point in time, so
if we find some bug and I fix it, I'll need you to test 4.1.0
out if you want it fixed.

OK, I have a bunch more info about this problem, plus an acceptable solution 
(at least for me).  The problem seems to be directly related to using kdm for 
login.  If I use gdm (gnome's version) the problem goes away.  I can change 
resolutions to my hearts content and everything works fine.  I did try 
disabling DRI while using kdm and I could change resolutions just fine.  With 
DRI enabled while using kdm I could not change resolutions at all.  I tested 
this between 800x600 and 640x480 and also between 1280x1024 and 640x480.  I 
discovered this because mharris asked for error logs without running kdm, gdm, 
or xdm so I entered runlevel 3 and ran startx.  When I started X that way 
everything worked fine.  So then I changed from using kdm to gdm and tried it 
again and everything worked fine.  The problem only appears if I use kdm with 
DRI enabled.  I am still able to use KDE as my desktop, I just can't use kdm 
to login.  I was unable to locate anyplace which logged any error messages 
when kdm crashes.  I checked /var/log/XFree86.0.log, but it didn't have 
anything unusual.  Hope this helps solve the problem.  For now, I've changed 
to using gdm for login while continuing to use KDE as my desktop.  Let me know 
if you need anymore info.

Just wanted to point out that I can CONFIRM everything that carl has noted.  
This problem ONLY happens when using kdm as the login manager.  Using either gdm or xdm 
makes the problem go away.  Can we investigate with the KDE people WHY kdm causes this 
problem?  I am a KDE addict and KDM is much easier for my people to use (in an office and 
home setting) than gdm.  Just wanted to say that I can confirm what carl has stated.

Just one more note, I AM using the rawhide XFree86 4.1.0-3 packages  (also with a Voodoo3 
AGO 16Mb video card) for my testing.  I hope that all of this information leads to this bug getting 
squashed.

I don't think it has something to do with KDM/GDM or anything alike. I am
running GDM and still have te problem in Redhat 7.1. 
Meanwhile I also installed Slackware 8.0 with kernel 2.4.5 and XFree 4.1.0 with
KDE and KDM running, and there the problem occurs a lot less than in Redhat 7.1. 
Now it depends on randomness. Sometimes X chrashes and leaves my consoles
unusable (the originaly described problem), but most of the time I can switch
modes without an problem.. It's a bit like gambling.. ;-)
So I guess, like mharris already mentioned before, it has something to do with
memory usage and DRI..

I disabled DRI on my Voodoo3 16Mb AGP and set 'DESKTOP="KDE"' in /etc/sysconfig/desktop 
so that kdm gets used as the login manager.   After disabling DRI, everything works fine now.  
Again, I am using the XFree86-4.1.0-3 packages that are in rawhide.  So, this (TO ME) appears 
to be a problem with kdm & Voodoo3 w/ DRI enabled.  I have not had a problem with changing 
resolutions once DRI was disabled.  Just to reinforce :) - this problem does NOT happen with 
either xdm or gdm for me.  I would strongly suggest that everyone pull down the latest 
XFree86-4.1.0 packages (you will need the Mesa packages as well, maybe a few others) and 
test this.  That way, we get hopefully track this bug down and get rid of it.  Can someone at 
RedHat explain what the package 'kernel-dri-4.1.0' is.  I just --force 'd the package installation.

As I said before, you can _NOT_ use resolution greater than 1024x768 on
a Voodoo 3 and expect it to not crash or misbehave.  If DRI is enabled
in the config, then wether or not you actually use DRI, it requires
memory, and you will experience odd problems if you have not used a low
enough resolution.  This is _not_ a limitation of Red Hat Linux, Mandrake,
or any other distro.  It is a limitation of XFree86, which does not allow
the reallocation of hardware resources.  As such, when using DRI with any
video hardware, there is a maximum resolution that you can use that is
lower than the maximum resolution you can use for non-DRI configurations.
On 32Mb and higher cards, this is not generally an issue because the cards
have ample RAM for 2D and 3D.  With 16Mb and less, it is indeed a problem.

So, the only way to solve this problem is first to ensure you have a sane
configuration.  That is described above.  Lower your res to 1024x768, or
disable DRI.  Once you have done that, if the kdm problem persists, please
attach your current config file, and X server log.

Future versions of XFree86 will at some point likely change the way this
limitation affects people, once RandR is in, I suspect they will rework
the allocation of resources, so that 2D resources can be reclaimed, and
then your 2D resolution wont affect fullscreen DRI operation, only windowed
operation.

Please update the report after trying what I have suggested, and I will
look into it again.

Thanks

I'm closing this bug, as I've now been able to thoroughly test this out
with both a Voodoo 3, and a Voodoo 4 card.  If using a configuration that
is known to be supported, there are no problems encountered when VT
switching for me other than a separate bug related to VGA font corruption
on VT switch of which I've just made a test fix for.

I will be adding code into the tdfx driver which will disable DRI if
16bit depth is being used with a mode higher than 1024x768 on 16Mb
cards, and display a warning to the X console and log.  This should
prevent many lockups and odd behaviours from happening.

The new changes will appear in rawhide shortly.

I'm not sure this fix is sufficient.  I have the same problem (Voodoo 3 16MB,
RedHat 7.2 all errata): consistent crashing under kde, occasional crashing under
gnome, no crashing with DRI disabled.  So I attempted the following workaround:
I ran with two Xservers, :0 at 1280x1024 with DRI disabled, and :1 at 1024x768
with DRI enabled.  After a while running this way (switching back and forth,
switching resolutions, etc.) it would still break virtual consoles 1-6.  So the
proposed fix will probably not help if someone runs with a similar configuration.