Hide Forgot
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 How reproducible: Always Steps to Reproduce: 1. Start system 2. wait 3. Actual Results: Sytstem will freeze solid within a day or two. Expected Results: System should not freeze in an unrecoverable condition. Additional info: 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 compiled myself.
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 server. 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. Thanks. Steve Feehan
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 ***