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): xorg-x11-6.7.0-2 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 2. 3. 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:
Created attachment 100414 [details] Xorg startup log This is the log for X after it froze (obtained by sshing in remotely)
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.
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-2.1.253.2.1, 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.
I tried xorg-x11-6.7.99.902-4 from rawhide and that didn't help.
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! Changing 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?
Created attachment 103116 [details] A working xorg.conf
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.
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 kudzu 1.1.68.2-1.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)
Tried latest 16k stack kernel. Seemed somewhat better but still locked up under heavy load but may have taken longer, hard to say.
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.
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: http://fedora.redhat.com/download 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" component. 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".