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): XFree86-4.2.0-8 How reproducible: Always 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).
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.