This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 38717 - (voodoo 3) XFree crashes and starts doing weird things on my tty's when changing resolution with AGP voodoo3 on K6-2
(voodoo 3) XFree crashes and starts doing weird things on my tty's when chang...
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
7.1
i586 Linux
high Severity high
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-05-02 06:29 EDT by Need Real Name
Modified: 2005-10-31 17:00 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-10-15 05:44:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2001-05-02 06:29:02 EDT
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.

Reproducible: Always
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
requested resolution

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.

Section "ServerLayout"
        Identifier     "Anaconda Configured"
        Screen      0  "Screen0" 0 0
        InputDevice    "Mouse0" "CorePointer"
        InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"

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

    RgbPath     "/usr/X11R6/lib/X11/rgb"

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

    FontPath   "unix/:7100"

EndSection

Section "Module"
        Load  "GLcore"
        Load  "dbe"
        Load  "extmod"
        Load "fbdevhw"
        Load "pex5"
        Load "dri"
        Load  "glx"
        Load  "pex5"
        Load  "record"
        Load  "xie"
EndSection

Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "keyboard"

#       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"
# or:
#       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"    ""
EndSection

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "IMPS/2"
        Option      "Device" "/dev/input/mice"
        Option      "ZAxisMapping" "4 5"
        Option      "Emulate3Buttons" "no"
EndSection

Section "Monitor"
        Identifier   "Monitor0"
        VendorName   "Monitor Vendor"
        ModelName    "Monitor Model"
        HorizSync   30.0-95.0
        VertRefresh 50.0-160.0

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

EndSection

Section "Device"
        # no known options
        Identifier   "Voodoo3 (generic)"
        Driver       "tdfx"
        VendorName   "Voodoo3 (generic)"
        BoardName     "Voodoo3 (generic)"

        #BusID
EndSection

Section "Screen"
        Identifier   "Screen0"
        Device       "Voodoo3 (generic)"
        Monitor      "Monitor0"
        DefaultDepth    16
        Option "DPMS"
        Subsection "Display"
                Depth       16
                Modes       "1280x1024" "1024x740" "800x600" "640x480"
"320x200"        EndSubsection

EndSection

Section "DRI"
        Mode 0666
EndSection
Comment 1 Mike A. Harris 2001-05-15 06:25:11 EDT
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?
Comment 2 Need Real Name 2001-05-15 07:57:38 EDT
I tried the version you gave me, but the problem stays..nothing changed.
Comment 3 carl 2001-06-04 11:01:10 EDT
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.
Comment 4 James Pattie 2001-06-04 15:13:55 EDT
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.
Comment 5 romano 2001-06-11 05:24:04 EDT
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...
Comment 6 Need Real Name 2001-06-12 07:51:13 EDT
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.
Comment 7 romano 2001-06-12 07:57:12 EDT
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. 
Comment 8 carl 2001-06-12 11:02:01 EDT
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.

Comment 9 Mike A. Harris 2001-08-08 09:31:14 EDT
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.
Comment 10 Need Real Name 2001-08-08 16:43:00 EDT
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.
Comment 11 carl 2001-08-14 12:11:28 EDT
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?
Comment 12 Need Real Name 2001-08-14 18:38:10 EDT
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
Comment 13 carl 2001-08-14 18:47:47 EDT
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?

Comment 14 Mike A. Harris 2001-08-15 07:18:49 EDT
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.
Comment 15 Mike A. Harris 2001-08-15 07:21:14 EDT
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.
Comment 16 carl 2001-08-15 16:30:36 EDT
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.

Comment 17 Need Real Name 2001-09-20 18:44:58 EDT
Just wanted to point out that I can CONFIRM everything that carl@boeckeler.com 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.
Comment 18 Need Real Name 2001-09-20 18:57:32 EDT
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.
Comment 19 Need Real Name 2001-09-20 20:35:59 EDT
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..
Comment 20 Need Real Name 2001-09-22 10:36:26 EDT
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.
Comment 21 Mike A. Harris 2001-09-22 10:54:58 EDT
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
Comment 22 Mike A. Harris 2002-02-03 08:59:10 EST
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.
Comment 23 Andre 2002-02-06 19:28:32 EST
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.

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