Red Hat Bugzilla – Bug 52178
X server (permedia2) locks the system, preferably when running a screen saver
Last modified: 2007-04-18 12:36:05 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2smp i686)
Description of problem:
On my Pentium II biprocessor machines equipped with a Fire GL 1000 PRO
graphics card (Permedia2 chip, 8 MB video RAM), the X server locks up the
system frequently. Observations:
1) It happens always almost when I leave the Gnome screensaver running for
some minutes (the energy saving feature is disabled)
2) It happens mostly with the screensaver, but occasionally during normal
3) The screen display remains static, keyboard and mouse have no effect,
even Ctrl-Alt-Del doesn't work.
4) It is still possible to log in remotely. I can then observe that the X
server uses 99% of the CPU (from "top"). Killing the X server, or any other
measure short of rebooting, does not help.
The problem occurs on two identically configured machines and started
exactly with the update from 6.1 to 7.1, therefore I don't suspect hardware
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Wait for the Gnome screen saver to come up
2. Wait for about five minutes
Actual Results: The system hangs.
Expected Results: Nothing!
Created attachment 28694 [details]
THis problem was fixed in an unofficial update I made, which can
be downloaded from: ftp://people.redhat.com/mharris/testing/7.1
be sure to get the updated Mesa package as well, etc..
The above package was planned on being an official errata, however
I am holding off for an XFree86 4.1.0 errata instead, which also
fixes this problem, so Rawhide has the latest code, but the 4.0.3
package above is much more stable currently. Up to you which one
you'd like to try.
Thanks, that seems to solve the problem, after two days of testing I am
reasonably certain. However, the update produces a new bug: when getting back to
work after a screensaver has been active, in some cases (estimated 1 in five)
the redrawing functions are severely impaired. The background doesn't get
redrawn properly, and some program's window contents look very bad as well. I
have never had this problem before the update.
I guess this is a different bug that should be reported separately, but how can
I report a bug on an unofficial bug fix???
My success report was premature: one of the machines crashed again a few minutes
ago, with exactly the same symptoms. It definitely happens less often after the
update, but the problem is not solved yet.
Upgrade to the Rawhide packages then. The 4.0.3 packages are unofficial
and not supported. No further bugfixing will be done on 4.0.x. All
official bugfixes for RHL 7.1 XFree86 are now in rawhide. I leave the
4.0.3 packages there only as a convenience.
4.1.0-0.99.1 is current release, avail on my ftpsite in the bleeding-edge
Does it fix the problem?
Sorry, I can't test 4.1 right away, the RPMs require glibc 2.2.3, whereas my
system has 2.2.2 and Rawhide already has 2.2.4.
Does XFree 4.1 require glibc 2.2.3 or would it be OK to recompile the SRPMs on
The 4.1.0 libs were built against glibc 2.2.3 but it is not a requirement
of XFree86. You can rebuild it against any glibc.
Sorry, but I have to give up. I had to update RPM to be able to process the
SRPMs, fine, no problem. Then I discovered that the XFree SRPM requires me to
update gcc as well. That is a risk I do not want to take; my machines are used
for work (including development), not for compiler testing.
If there is no other way to get a stable X environment, I'll have to go back to
RedHat 6.2 for the moment.
You do not need the newer gcc to build X, you just need to reconfigure
the specfile to use the older gcc. It is a conditional define at the
top. Change DisableModuleStringMerging to 1:
%ifnarch s390 s390x
%define DisableModuleStringMerging 1
%define DisableModuleStringMerging 0
Set the lower one to "1" instead of "0"
After two days of compiling, here's where I am
1) After setting DisableModuleStringMerging to 0, there was a problem in
building libbitmap. I tracked it down to the definition
#define ModuleRanlibCmd RanlibCmd
missing when module string merging is not disabled.
2) With that modification, I can build the RPMs without error messages. However,
when I try to install them, rpm complains that libXxf86dga.so.1 is missing. The
comments in the spec file indicate that this file was removed on purpose, but
apparently it is still needed under some conditions.
3) Since I don't really need DGA, I set BuildXF86DGA to NO and tried again.
This time, the compilation stopped without any reason that I could identify:
gcc -O2 -march=i386 -mcpu=i686 -pipe -ansi -pedantic -Wall -Wpointer-arith -I.
-I../../../../../../exports/include -Dlinux -D__i386__
-D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE
-D_SVID_SOURCE -D_GNU_SOURCE -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP
-DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPIXPRIV -DPANORAMIX
-DRENDER -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXvExtension
-DXFree86LOADER -DXFree86Server -DXF86VIDMODE -DSMART_SCHEDULE -DBUILDDEBUG
-DX_BYTE_ORDER=X_LITTLE_ENDIAN -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO
-DIN_MODULE -DXFree86Module -c IBM561ramdac.c
make: *** [tga_driver.o] Error 1
make: *** Waiting for unfinished jobs....
make: Leaving directory
For the moment I don't know what to do!
Sorry, bugzilla isn't a tech support forum.. I can only advise
to use a newer release and make some suggestions. Please use
firstname.lastname@example.org for help compiling XFree86. I'll update the
report when more info is available.