Bug 68615

Created attachment 64884 [details]
/etc/X11/XF86Config for affected machine

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.

Thanks.

Created attachment 65244 [details]
/var/log/XFree86.0.log from gdm-controlled X session

Minor correction to the original posting: the correct amount of VideoRam is
16MB.

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. 

Created attachment 68525 [details]
Workaround for single-user machines using gdm as display mgr

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

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
time,
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
xscreensaver-gl
and observing X to freeze in the GL-equipped starwars module.

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

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.

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.

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.

Hi-

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

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

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.