From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i586; en-US; 0.7) Gecko/20010316
When I change the resolution of XFree (using ctrl-alt-+ or -, or when a
program does so) the server switches to the requested resolution and then
it crashes.I am using KDM so XFree restarts automaticly, but when I press
ctrl-alt-F1->F6 I see my desktop in the current state but in the previously
requested resolution instead of getting my text tty's.
Steps to Reproduce:
1.Press Ctrl-Alt-+ or Ctrl-Alt-- or let a program change the resolution
(ex: mpeg player)
Actual Results: Xfree changes resolution and then crashes. When restarted
it starts displaying my current desktop on all tty's in the previously
Expected Results: Xfree should not crash and should not start doing weird...
I have a plain install of RedHat 7.1 with the latest updates recieved with
up2date. I run KDM.
I have a 3Dfx Voodoo3 with 16MB of memory, an AMD K6-2 500Mhz, 128 MB Ram
I can't find any significant error messages, I looked in
/var/log/XFree86.0.log and /var/log/messages.
my current XF86Config-4 file looks like this:
# File generated by anaconda.
Identifier "Anaconda Configured"
Screen 0 "Screen0" 0 0
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
# The location of the RGB database. Note, this is the name of the
# file minus the extension (like ".txt" or ".db"). There is normally
# no need to change the default.
# Multiple FontPath entries are allowed (they are concatenated together)
# By default, Red Hat 6.0 and later now use a font server independent of
# the X server to render fonts.
# Option "AutoRepeat" "500 5"
# when using XQUEUE, comment out the above line, and uncomment the
# following line
# Option "Protocol" "Xqueue"
# Specify which keyboard LEDs can be user-controlled (eg, with xset(1))
# Option "Xleds" "1 2 3"
# To disable the XKEYBOARD extension, uncomment XkbDisable.
# Option "XkbDisable"
# To customise the XKB settings to suit your keyboard, modify the
# lines below (which are the defaults). For example, for a non-U.S.
# keyboard, you will probably want to use:
# Option "XkbModel" "pc102"
# If you have a US Microsoft Natural keyboard, you can use:
# Option "XkbModel" "microsoft"
# Then to change the language, change the Layout setting.
# For example, a german layout can be obtained with:
# Option "XkbLayout" "de"
# Option "XkbLayout" "de"
# Option "XkbVariant" "nodeadkeys"
# If you'd like to switch the positions of your capslock and
# control keys, use:
# Option "XkbOptions" "ctrl:nocaps"
Option "XkbRules" "xfree86"
Option "XkbModel" "pc105"
Option "XkbLayout" "be"
#Option "XkbVariant" ""
#Option "XkbOptions" ""
Option "Protocol" "IMPS/2"
Option "Device" "/dev/input/mice"
Option "ZAxisMapping" "4 5"
Option "Emulate3Buttons" "no"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
# -- 1400x1050 --
# 1400x1050 @ 60Hz, 65.8 kHz hsync
Modeline "1400x1050" 129 1400 1464 1656 1960
1050 1051 1054 1100 +HSync +VSync
# 1400x1050 @ 70Hz, 76.8 kHz hsync
Modeline "1400x1050" 151 1400 1464 1656 1960
1050 1051 1054 1100 +HSync +VSync
# 1400x1050 @ 75Hz, 82.3 kHz hsync
Modeline "1400x1050" 162 1400 1464 1656 1960
1050 1051 1054 1100 +HSync +VSync
# 1400x1050 @ 85Hz, 93.2 kHz hsync
Modeline "1400x1050" 184 1400 1464 1656 1960
1050 1051 1054 1100 +HSync +VSync
# no known options
Identifier "Voodoo3 (generic)"
VendorName "Voodoo3 (generic)"
BoardName "Voodoo3 (generic)"
Device "Voodoo3 (generic)"
Modes "1280x1024" "1024x740" "800x600" "640x480"
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
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
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
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 firstname.lastname@example.org 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
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
Please update the report after trying what I have suggested, and I will
look into it again.
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.