Bug 123883 - X freezes after short time, mouse cursor movable but useless
X freezes after short time, mouse cursor movable but useless
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
athlon Linux
medium Severity high
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2004-05-21 06:52 EDT by Mark Adams
Modified: 2007-11-30 17:10 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-06 15:39:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Xorg startup log (34.48 KB, text/plain)
2004-05-21 06:55 EDT, Mark Adams
no flags Details
A working xorg.conf (2.83 KB, text/plain)
2004-08-26 09:24 EDT, Carl-Johan Kjellander
no flags Details

  None (edit)
Description Mark Adams 2004-05-21 06:52:14 EDT
Description of problem:

After upgrading to Fedora Core 2, X freezes on me after a short period
of time (usually between 30 secs and 5 mins). The mouse cursor is
movable on the screen, but I cannot click anywhere. The keyboard is
non-responsive, and I cannot switch to any other virtual terminal.
Note that even trying to turn numlock on/off doesn't work.

I can ssh into the machine remotely, and the only thing out of the
ordinary is that X is spinning at 100% cpu. There isn't anything
obviously out of the ordinary in either the system log or the Xorg log.

Switching to runlevel 3 doesn't restore the screen/keyboard, but then
subsequently switching back to runlevel 5 does.

Here's what I've found to date:
- happens when logged in using either gnome or kde
- most easily reproducible with mozilla, although I've also had it
happen with evolution and with just a gnome terminal
- reproduced on a clean install of Fedora Core 2 in a separate
partition, so it's not an upgrade issue or something left around from
using the binary Nvidia drivers in Fedora Core 1 (which I did remove
prior to upgrading to Fedora Core 2)
- when X freezes, there is often a visual artifact or two on the
screen (a couple of jagged lines)
- tried booting with acpi=off, no difference

If I switch the driver from 'nv' to 'vesa', X is stable (although
noticably slower). Noticing on the X.org site that the nv driver was
recently rewritten, I'd initially suspect that as the culprit.

System information:
- Asus A7V133 with AMD Athlon 1.2GHz
- 512M RAM
- NVidia GeForce 2 MX AGP card
- NEC LCD 1712 17" monitor

I am happy to provide any further information that would be of use
debugging this and/or testing fixes, as my current situation is
waiting to see which happens first: nv driver getting fixed or NVidia
updating their binary driver for FC2. :/

Version-Release number of selected component (if applicable):

How reproducible:
Consistently within 5 minutes of starting X

Steps to Reproduce:
1. use a program which does a lot of activity on-screen (mozilla or
evolution for example) for a few minutes after startup
Actual results:
X freezes resulting in a system that has to be reset manually or
logged into remotely

Expected results:
X doesn't freeze. :>

Additional info:
Comment 1 Mark Adams 2004-05-21 06:55:25 EDT
Created attachment 100414 [details]
Xorg startup log

This is the log for X after it froze (obtained by sshing in remotely)
Comment 2 Peter van Egdom 2004-06-07 15:57:45 EDT
The problem described here looks like the problem reported in Bugzilla
bug 101547.

What happens when you run the following command :

  "x11perf -v1.3 -rop GXcopy GXxor -repeat 2 -time 1 -all"

On my system X crashes with this command within 1 minute or so, so
close any important programs you're running.
Comment 3 Carl-Johan Kjellander 2004-08-20 09:36:02 EDT
I'm seeing this one as well. X freezes, but mouse still moving,
after 30 seconds, usually when staring mozilla, emacs or x11perf.

Dual AthlonMP 1800+, ASUS A7M266-D Motherboard, ATI Radeon 9200SE.

kernel-smp-2.6.7-1.494.2.2, xorg-x11-6.7.0-5.

I had trouble with this just before FC2 came out in rawhide,
then the problem went away with a rawhide update and X was
running fine for months at a time all summer.

I just started updating to latest FC2 updates and the problem
resurfaced. X takes 100% CPU on one processor, mouse still working.
The kernel takes most of the other CPU. Can still ssh in, but
can't kill X. No really useful messages in logs.

I've tried different older kernels back to
kernel-smp-2.6.3-, both smp and up, and with both
noapic and pci=noacpi but that didn't help.

Should I try to downgrade xorg again?

Any tips on working around this one? Cause the system is unusable in
X right now.

Comment 4 Carl-Johan Kjellander 2004-08-25 06:03:28 EDT
I tried xorg-x11- from rawhide and that didn't help.
Comment 5 Carl-Johan Kjellander 2004-08-26 09:22:29 EDT
I started playing around with my xorg.conf to try to work around the
problem and I found what triggered the freezes in my case!

        Option      "AGPMode" "4"

which I had before to
        Option      "AGPMode" "2"

x11perf has been running for 20 minutes now and no freeze yet.

Is this an X11 or kernel problem in my case? Should I try
different options for AGP in xorg.conf or in BIOS?
Comment 6 Carl-Johan Kjellander 2004-08-26 09:24:45 EDT
Created attachment 103116 [details]
A working xorg.conf
Comment 7 gene smith 2004-10-03 15:55:18 EDT
I have been having this problem since fc2 test. All kernels seem to
have the problem for me. Total X lockup. Only the mouse will move and
no keyboard response. Ctl-Alt-BkSp non-functional. I have no scsi,
just IDE drive and GeForce3 Ti 200 card using standard stock
fedora/xorg drivers. Can go to another computer and log in using vnc
with no problem and restart or shutdown system and/or X. Observe via
vnc the X process is running about 97% cpu with 3% memory when locked.
CPU is 500 Mhz athlon. Memtest works fine on overnight tests. See
nothing in logs indicating a problem. Ctl-Alt-(keypad)/ or (keypad)*
enabled in xorg.confg but do nothing during lock. Have reported this
several time on list. Have completely updated fc2. At times has seemed
to be fixed but alway occurs eventually (several times a day to once a
week when x heavily loaded with lots of windows to just a few). Have
seen with kde and gnome.

Comment 8 Christophe Lambert 2004-10-05 05:13:21 EDT
I have the same problem.

X is frozen (99% CPU) after a few minutes. It is higly reproducible
when resizing a lot of times applications like evolution, emacs,
xemacs and mozilla. It freezed also one time in gnome-terminal.
It does not depend on KDE or GNOME. Nevertheless there is a
difference: a simple kill -9 X PID restart X when in KDE. When in
Gnome I need to kill X PID, telinit 3 and telinit 5 after several seconds.
I ran x11perf (AC #1) with no problem.
I tried to set the VESA and VGA drivers but they didn't work (I have
to check the resolution to be sure)
Something I think is important is that FC 2 ran with no problem since
the FC2 release date. The problems arrived after September 15 when
updating to the following packages:
Package Installed:
   kernel 2.6.8-1.521.i686
Package Dependency Installed:
   kdebase-devel 6:3.2.2-6.FC2.i386
   kdelibs-devel 6:3.2.2-8.FC2.i386
   samba-common 3.0.7-2.FC2.i386
   samba-client 3.0.7-2.FC2.i386
Package Updated:
   imlib 1:1.9.13-19.i386
   lha 1.14i-14.1.i386
   kdebase 6:3.2.2-6.FC2.i386
   cdda2wav 8:2.01-0.a27.4.FC2.3.i386
   cdrecord 8:2.01-0.a27.4.FC2.3.i386
   mkisofs 8:2.01-0.a27.4.FC2.3.i386
   kdelibs 6:3.2.2-8.FC2.i386
   samba 3.0.7-2.FC2.i386

Even if X is frozen and run at 99% CPU, other applications continue to
run. XMMS still continue to read music and Evolution continue to
receive new mails.

I also tried with the latest xorg-x11 package from FC 3 test2 and the
problem still remains. As said in previous comments, it may be a bug
in the driver.

I am running FC 2 on 
AMD Athlon(tm) XP 2400+
NVIDIA GeForce4 MX 440

All updates have been done (before caracterizing bug)

I also installed RedHat Enterprise Linux 3 update 3 and had exactly
the same problem but only when running Emacs (RHEL  is using XFree86)
Comment 9 gene smith 2004-10-23 20:52:00 EDT
Tried latest 16k stack kernel. Seemed somewhat better but still locked
up under heavy load but may have taken longer, hard to say.
Comment 10 Christophe Lambert 2004-11-08 07:02:36 EST
After one month searching what is wrong, I finally found that the
NVIDIA GeForce4 MX 440 was altered.

I did tests under RedHat Fedora core 2, Fedora core 3 test 3, Redhat
Enterprise Linux 3 update 3, Suse Linux 9.1, Mandrake 10 and all
distributions had the same XOrg or XFree86 instability. I decided to
try the card on a MS-Windows computer and ... the computer crashed
after several seconds or minutes. I encourage all the people having
this problem to test the card on a MS-Windows installed computer. So
this "bug" may be not a bug but a hardware problem.

Nevertheless, it is difficult to explain why tests like x11perf can
run perfectly or why the computer is running without problems until
next reboot. I suspect some memory related problems or instructions
specific problems on the GeForce.
Comment 11 Mike A. Harris 2005-03-06 15:39:43 EST
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".

Note You need to log in before you can comment on or make changes to this bug.