Description of problem: When desktop is kept locked using xscreenlock overnight (or at times even for 1-2 hours) the system hangs, i.e. the system can be pinged from another host, but screen becomes 90% black with a thin strip looking like a 256 color raster scan at the bottom of the page. The keyboard inputs seem to be ignored (mostly), i.e. CTRL-BACKSPACE doesn't kill the XServer, and CTRL-ALT-Fn doesn't work either, although pressing ALT-CTRL-DEL 5-6 times does reboot the system (after quite some time). Version-Release number of selected component (if applicable): xscreensaver-4.16-2 How reproducible: Almost 100% Steps to Reproduce: 1. Lock desktop and leave running for about 7-8 hours 2. 3. Actual results: Expected results: Additional info: Could be related to bugId# 109009
Slightly different behaviour, even without Xscreenlock running... again I got a blank-screen, i.e. CTRL-DEL, ALT-CTRL-Fn etc. does not work, but I do not get that thin raster band at bottom of screen. I did a ps -ef to check for X server, and here is the output. # ps -ef | grep X root 6040 3933 0 13:03 ? 00:00:00 /bin/sh /etc/X11/gdm/XKeepsCrashing root 6057 6040 0 13:03 ? 00:00:00 /usr/libexec/gdmopen - l /bin/sh -c /etc/X11/gdm/XKeepsCrashing -noopen root 6068 6057 0 13:03 tty7 00:00:00 /bin/sh /etc/X11/gdm/XKeepsCrash ing -noopen root 6201 6182 0 14:01 pts/7 00:00:00 grep X
Created attachment 104115 [details] Xorg.0.log.zip
from the /var/log/Xorg.0.log file :-- Error in I830WaitLpRing(), now is 9322, start is 7321 pgetbl_ctl: 0x3ffe0001 pgetbl_err: 0x29 ipeir: 0 iphdr: 76b3ffff LP ring tail: 1a0 head: 5368 len: 1f001 start 0 eir: 0 esr: 10 emr: ffff instdone: 78c1 instpm: 0 memmode: 108 instps: 430 hwstam: ffff ier: 0 imr: ffff iir: 0 space: 20928 wanted 131064 FatalError re-entered, aborting lockup
And huh, BTW did i mention that doing: init 3 init 2 init 3 init 5 didn't help, i.e. the colored bar-code like thin raster line at the bottom of page didn't go, and i didn't get a new log-on screen. killing all X server & gdm server, also didn't help.
if you ssh into the box and check currently processes, are X processes still present? init 3 would be best since it would not attempt to respawn X. With a pre-CVS version and the same chipset, I noted this problem. I closed the bug, since the cvs build fixed it previously.
This bug was filed against Fedora Core 3 test1, which has been obsoleted by Fedora Core 3 test2. I have reassigned the bug to the correct component "xorg-x11", as we do not ship or support "XFree86" in Fedora Core 2 or later. Please upgrade to Fedora Core 3 test2 or test3 (once it's available), and then update the system to all of the latest packages available in rawhide. Please update the bug report to indicate if this problem still exists once your system is updated to current rawhide. Thanks in advance.
Since this bugzilla report was filed, there have been several major updates to the X Window System, which may resolve this issue. Users who have experienced this problem are encouraged to upgrade to the latest version of Fedora Core, which can be obtained from: http://fedora.redhat.com/download If this issue turns out to still be reproduceable in the latest version of Fedora Core, 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. Setting status to "CURRENTRELEASE".