From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.6 i686)
Description of problem:
This system is an Athlon Slot-A, AMD chipset, with a Riva TNT2 chip 32mb
video card. It was running 6.2 + some rawhide upgrades without any
problems. In June I upgraded to 7.1 and since that time the system has been
freezing hard at random intervals, usually 1 to 5 days. No keyboard or
mouse respone, no virtual consoles, cannot be accessed from net, ping gets
no response. The only way out is kill the power. The system is running a
self compiled 2.4.6 kernel and also happens with 2.4.5, 2.4.3
Steps to Reproduce:
1. Start system
Actual Results: Sytstem will freeze solid within a day or two.
Expected Results: System should not freeze in an unrecoverable condition.
I went back to a 2.4.3 kernel I had been using before upgrading to 7.1 and
before these lockups started. It now freezes also. The only common thread I
can find at the moment is all the freezes have occured while I was away
from the machine. It's fine while I'm at terminal doing stuff. Which has
lead me to think it is a problem with xsreensaver, XFree 4.0.3 and my video
( again it was working fine before 7.1) . I have a box a work that had the
same upgrade path and it has been rock solid but it has different hardware
All of the freezes have ocurred after xscreensaver has kicked in, usually
at night after going to bed. I get up the next morning, the screensaver is
on the screen and the box is frozen. I have disabled xscreensaver for now
to see if this helps any. There is no info in any of the log files related
to this, info stops making into the log file when the feeze occurs.
Since disabling xscreensaver the problem seems to have gone away. Up thirteen
days with no freezes. What in xscreensaver is causing the problem ?
I see this problem with my system, too. I'm running 2.4.3-12smp and have an S3
ViRGE GX/2 4MB AGP card on a Abit BP6 motherboard running XFree86-4. Pretty
standard RH 7.1 install. When it locks it doesn't even respond to SysReq key
sequences (which I've enabled). It happened under 2.4.2-2 and another kernel I
Hardware: ASUS A7M266 Motherboard, Athlon processor with AMD 761 Chipset
BIOS upgraded from v1004a to v1005
256 MB RAM
ATI XPERT 2000 (Rage 128 RL) Video card
Software: OS: RH7.2 with current patches, Kernel 2.4.9-13.athlon
I have been having similar problems. I was usually able to force a system
lockup/crash by running the "sproingies" xscreensaver from gnome. (I didn't try
it under KDE as KDE would crash the system on startup, see below.) These
failures ranged from a simple X-lockup to a warm reboot.
i.e. xscreensaver -verbose -no-splash -timeout 1 -nice 10 -no-dpms -xrm
"*programs: sproingies -root"
Other programs like xmms or plaympeg seemed to cause serious insatiabilities as
well, but it was a less direct a connection. e.g. It seemed as if I could run
all day if I hadn't used xmms. However, the system MIGHT eventually lockup
within an hour or two of using XMSS.
In a possibly related note, KDE would crash the entire system on startup until I
upgraded the BIOS from v1004a to v1005. The system seems more stable after the
upgrade, but there are still problems. (see below)
My gut feeling is the real bug is elsewhere but "sproingies" was able to
exercise it. I've run some tests with the Mesa demos and have some crash data.
As I can't be sure it's related to this bug, I have opened a new bug report, #57509
I have seen the same problem on several recent 7.1/2 installs. The systems are a
combination of Athlons and P4s, with TNT2 and ATI Radeon cards.
Usually the system is available through the network, I can ssh and kill the X
The problem always occurs while the screensaver is running. It usually happens
overnight while I'm at home.
I've also noticed that occasionaly there are MANY screensaver hacks running at
the same time. I'm not sure why this would be, and have never seen it before.
If the system locks, that indicates a kernel or XFree86 problem.
Well those who can still ssh in don't have a kernel problem at least...
*** This bug has been marked as a duplicate of 73827 ***