Red Hat Bugzilla – Bug 132968
X hangs -- (was: system hangs when xscreenlock is used to lock desktop)
Last modified: 2007-11-30 17:10:49 EST
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):
Steps to Reproduce:
1. Lock desktop and leave running for about 7-8 hours
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
root 6201 6182 0 14:01 pts/7 00:00:00 grep X
Created attachment 104115 [details]
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
And huh, BTW did i mention that doing:
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
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:
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"
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".