Bug 68615 - XFree86 server on ATI Rage 128 hangs after switch back from text mode
Summary: XFree86 server on ATI Rage 128 hangs after switch back from text mode
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 7.3
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: David Lawrence
Depends On:
Blocks: screensaver 82779
TreeView+ depends on / blocked
Reported: 2002-07-11 18:28 UTC by Robert K. Moniot
Modified: 2007-04-18 16:44 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-09-24 16:38:09 UTC

Attachments (Terms of Use)
/etc/X11/XF86Config for affected machine (3.76 KB, text/plain)
2002-07-11 18:29 UTC, Robert K. Moniot
no flags Details
/var/log/XFree86.0.log from gdm-controlled X session (31.53 KB, text/plain)
2002-07-13 16:13 UTC, Robert K. Moniot
no flags Details
Workaround for single-user machines using gdm as display mgr (445 bytes, patch)
2002-08-02 18:03 UTC, Robert K. Moniot
no flags Details | Diff

Description Robert K. Moniot 2002-07-11 18:28:18 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.79 [en] (X11; U; Linux 2.4.18-5 i686)

Description of problem:
Running the XFree86 server on a Dell Optiplex GX240.  When I switch to console
using Ctrl-Alt-F1 and then back to X, a greenish band appears at the top of the
screen, and the keyboard and mouse are frozen.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Start X either by entering runlevel 5 or using startx from a console login
2. Hit Ctrl-Alt-F1 to go to console text mode
3. Hit Ctrl-F7 to return to Xwindows

Actual Results:  X window appears, but garbaged with some sort of usually
greenish band
across the top 100 or so pixel rows.  Keyboard and mouse stop responding.
Machine is still running and can be accessed remotely to kill X.  After X is
killed and then restarted, it works OK.

Expected Results:  Should return to normal X behavior.

Additional info:

The X server is /usr/bin/X11/XFree86 4.2.0-8 with XF86config produced by
anaconda during system installation.   Problem has been seen with all
kernels installed from kernel-2.4.18-3 to kernel-2.4.18-5.  I have seen problem
only on Dell Optiplex GX240 with ATI Rage 128 (64K VideoRam).  We have
several of those and all behave alike.

With the initial RedHat 7.3 installation, this freezing behavior would also
happen spontaneously if machine were left idle for a half hour or so.  That
aspect of the behavior disappeared after some update or other (probably
kernel 2.4.18-4).

Comment 1 Robert K. Moniot 2002-07-11 18:29:31 UTC
Created attachment 64884 [details]
/etc/X11/XF86Config for affected machine

Comment 2 Mike A. Harris 2002-07-12 21:53:23 UTC
Can you attach the X server logfile as well please?  This problem sounds
quite unique to the specific hardware.  Might be tricky to isolate perhaps.

You mention 64K of video RAM.  Do you mean 64Mb of video RAM?  I haven't
seen any 64Mb R128 boards yet myself.  I haven't seen any 64Kb ones either
though.  ;o)  Not since 1989 or so anyway.  ;o)

Give me as many details as possible, and I'll try to look into it.


Comment 3 Robert K. Moniot 2002-07-13 16:13:04 UTC
Created attachment 65244 [details]
/var/log/XFree86.0.log from gdm-controlled X session

Comment 4 Robert K. Moniot 2002-08-01 01:51:09 UTC
Minor correction to the original posting: the correct amount of VideoRam is

Comment 5 Robert K. Moniot 2002-08-02 18:02:38 UTC
I have found a workaround that is acceptable for single-user machines
that use gdm as the display manager.  It simply modifies the gdm PostSession
script to force shutdown and restart of X at the end of every session.  The
restart clears whatever is causing the problem.  I am attaching the patch that
I have put in place on affected machines. 

Comment 6 Robert K. Moniot 2002-08-02 18:03:47 UTC
Created attachment 68525 [details]
Workaround for single-user machines using gdm as display mgr

Comment 7 Robert K. Moniot 2002-08-02 18:19:32 UTC
In the original bug report, I said " this freezing behavior would also
happen spontaneously if machine were left idle for a half hour or so.  That
aspect of the behavior disappeared after some update or other".  I have learned

A colleague who also helps maintain these machines traced the "spontaneous"
bad behavior to GL-equipped modules of xscreensaver.  We are running
xscreensaver-4.03-1.  If xscreensaver-gl-4.03-1 is also installed, then at
some point X will freeze while xscreensaver is running one of the GL modules.
For instance, it froze while running /usr/X11R6/lib/xscreensaver/starwars.
It doesn't freeze immediately.  The screensaver will run fine for a period of
typically about a half hour, before freezing.  My colleague uninstalled
xscreensaver-gl some time ago, and that is why the "spontaneous" freezing
stopped.  We verified that the problem still exists by re-installing
and observing X to freeze in the GL-equipped starwars module.

This means that anyone with the same problem should uninstall xscreensaver-gl.

Comment 8 Mike A. Harris 2002-11-04 09:07:15 UTC
Lockup problems with the starwars screensaver occur with a lot of different
hardware, in particular Matrox hardware, and Radeon/R128 hardware also.

This problem is due to a long standing bug in the kernel DRM locking, and
is believed to be fixed in the latest Red Hat Linux 8.0 kernel erratum.

I'm not sure if the same bug fix is present in our latest 7.3 kernel, but
if it isn't we should include it in future erratum also.  If you could
test our 7.3 kernel erratum out and provide me feedback on this issue
while testing the starwars screensaver, it would be much appreciated.

Alternatively, if you're using Red Hat Linux 8.0 already, if you could
let me know if the latest 8.0 kernel solves this problem for you or not,
that would also be useful.

Comment 9 Mike A. Harris 2002-11-04 09:09:29 UTC
I've got a tracking bug for the screensaver issue.  you might want to
check it out also, and the bug reports linked to it.  bug #73827

I've added this bug as a blocker to that one.

Comment 10 Robert K. Moniot 2002-11-07 21:25:50 UTC
I have upgraded one of the affected machines to RedHat 8.0.  The bug has gone
away, with both the installation kernel 2.4.18-14 and the update kernel
2.4.18-17.7.x.  I did not test it on the starwars screensaver since I could not
locate it on my system or in the RH8.0 CD set.  I tested it using Ctrl-Alt-F1 to
switch from Xwindows to console mode, then Alt-F7 to switch back, with no
problems.  Sometimes upon switching into Xwindows there briefly appears a
hatched stripe about an inch wide across the top of the screen, which seems to
be the same as the garbaged appearance previously seen, but this disappears in a
tenth of a second or so, and all is back to normal.

I think this means the bug is resolved, but I leave that determination to you
guys.  Thanks.

Comment 11 Sean O'Connell 2002-12-26 04:30:24 UTC

I am seeing this same behavior on Dell Optiplex GX-260 machines with the ATI
Radon 7500 cards in it. The weird band across the top of the screen and then
loss of all keyboard and mouse (an ssh in and reboot is the only fix). All of
the machines are running redhat 7.3 with nearly the latest kernel rpm
(2.4.18-18.7.x) and the latest XFree86 (4.2.0-8). I have seen the behavior at
both 16 and 24 bit and various resolutions.

I did see one mention of this problem in a google search. The discussion was on
 one of the Debian lists:

Newsgroups: linux.debian.maint.x
Subject: XFree86 freeze after switching to console

A mention was made of a fix for both the r128 and radeon drivers that made it's
way into the CVS tree for XFree86 (that was in October).

Output from lspci -v
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV200 QW [Radeon
7500] (prog-if 00 [VGA])
	Subsystem: ATI Technologies Inc: Unknown device 103a
	Flags: bus master, stepping, 66Mhz, medium devsel, latency 64, IRQ 11
	Memory at f0000000 (32-bit, prefetchable) [size=128M]
	I/O ports at ec00 [size=256]
	Memory at ff8f0000 (32-bit, non-prefetchable) [size=64K]
	Expansion ROM at 80000000 [disabled] [size=128K]
	Capabilities: [58] AGP version 2.0
	Capabilities: [50] Power Management version 2

Comment 12 Sean O'Connell 2002-12-30 15:22:07 UTC
As a follow-up, if I disable dri in the XF86Config-4 and reboot (make sure the
radeon module is no longer loaded), I am able to use my virtual consoles without

Comment 13 Mike A. Harris 2004-09-24 16:38:09 UTC
We believe this issue to be resolved in our currently shipping
OS releases.  Please upgrade to Fedora Core 2 or later, and if this
issue turns out to still be reproduceable, please file a bug report
in the X.Org bugzilla located at http://bugs.freedesktop.org in the
"xorg" component.

Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes
that become available for consideration in future updates.

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