F14 freeze : How to diagnose?

[peter_sm]

How would I work out what nvidia driver I need?

The Graphic card is a Gigabyte NX-57128P

[peter_sm]

I did a full reboot with F14, and it is all good now.

[bob p]

I am having the same problems on a fresh F14 install from the i686 DVD -- unprovoked KB/mouse lockups on a freshly installed system.

As soon as the install is completed I open a console window in Gnome, SU to root, and perform a yum update to bring in 480+ package updates. The KB and mouse lockup but Yum keeps on working until it reaches the point that it prompts the user for "Y/N" input and then it stops because the keyboard doesn't work. With the keyboard and mouse both frozen, my only option is to reboot.

Following a reboot I have yum resume the update. It completes the update and installs a new kernel and the problem repeats itself. The kernel update and the package updates and the reboots don't solve the problem.

I haven't paid any attention to the time interval, but it may be in the area of 15-30 minutes or so after boot, and it occurs in spite of KB and mouse activity -- it does not seem to be related to an inactivity timer as it will happen while I'm using the desktop.

Brand new hardware:

ASUS P7P55D Deluxe motherboard.
8 GB Corsair Vengeance 1866 DRAM
Intel i5 760 with stock clock.

Old hardware:

nvidia GeForce2 MX 200 PCI card (don't laugh!)

No proprietary nvidia video drivers have been installed. The only packages are in the standard Fedora DVD distribution and the standard fedora upgrade repository.

This problem seems related to software rather than hardware, and it seems specific to Fedora 14. I had Centos 5.5 installed on the box in a mono-boot config for a couple of weeks without problems before deciding to switch to F14 in a mono-boot config. The problem came up immediately upon installing F14. After encountering the problem I got hold of a copy of Win 7 Home Premium for a test install (mono boot config) and it works just fine. I reinstalled F14 a second time in a dual-boot config and the problems are 100% repeatable on the new install. Win7 works fine, F14 locks up.

It seems that F14 is the culprit and that the nvidia proprietary drivers are NOT a factor in the problem as they aren't even installed on the box.

Warmboots, Coldboots, and Power-Off x5 minute coldboots don't solve the problem.

[jjdutton]

I have a Nvidia 9500GT installed and when I installed Fedora 14 followed by Google Earth I kept getting a message from Google Earth about Directx and Emulation. I checked the system and no Nvidia drivers were installed with Fedora 14. I then performed: yum install akmod-nvidia. I then checked /lib/modules/2.6.35.10-74.FC14,I686/extra/ and Nvidia was present. Google Earth no longer runs in emulation mode and I have not had any system hangs with heavy system usage.

I also performed the same process to reinstall the Nvidia drivers in Fedora 13 when a kernal update obliterated the Nvidia folder because Nvidia drivers were not distributed with that particular update.

Maybe some problems will be eliminated with this info.

[Vespa]

CentOS comes with Xorg Server version 1.1.1 using the NV driver by default where as Fedora 14 comes with Xorg Server version 1.9.0 using the Nouveau driver which could explain the difference. Since you have an older graphics card, perhaps you may have better results using the proprietary driver from either Nvidia ( http://www.nvidia.com/object/linux-d...19-driver.html ) or the kmod-nvidia-96xx or kmod-nvidia-96xx-PAE driver from RPMFUSION. They have added support for the 1.9.0 Xorg server. Nouveau sould work with your card, but it isn't perfect.

I am making the assumption freezing only occurs in a graphical boot correct? If you boot to runlevel 3 and you still get freezups, you may want to check your dmesg log.

[Marcuccio]

So also F14 suffers of a misterios bug able to completely freeze the system and related to graphics
It's incredible how this very serius bug can survive so long. In my opinion it has existed since Fedora 12.

http://forums.fedoraforum.org/showth...=238512&page=1 (F12)
http://forums.fedoraforum.org/showthread.php?t=245752 (F13)

I personally experienced the problem on f12 (unsolvable) and on f13 (solved installing nvidia proprietary driver , using akmod module)

I still have to test on f14 (waiting for another problem being solved)

My hw is ASUS P6TD + nvidia gt220 (very common hw i think)

I haven't a solution but in my opinion the bugs it's not strictly related to hw. I think some drivers are able to trigger the problem or to stop it, but the bug probably lie in Xorg.

I'm surprised, the situation is really serius and nobody is doing anything on it. It's also very hard to open a bug on bugzilla because, at least in my case, the system was completely frozen (no mouse,no keyboard, no remote login).


Marco

[LongTimeDabbler]

I completely agree with you Marco. I've got some new HW and been
dealing with FC14 (and FC13 for that matter). I think the problem
lies in Xorg because I see log messages in my Xorg.0.log file
like
PS2 Mouse: Event queue full!

And if I do a "tail" of the Xorg.0.log I've seen these msgs show up
just before the freeze.

When the freeze happens the computer is still working, screeensaver will
work, onscreen clocks will update, there is just no ability to handle
mouse or keyboard events.

I think this happened with various distros as the versions of Xorg got
more recent - with FC14 the Xorg version is 1.9.0.

Agree that the bug seems to be in Xorg - it would be nice if this got addressed or a workaround found.

John

[LongTimeDabbler]

I swapped the PS2 mouse for a USB mouse and at least so far,
things are good. Let's see how it goes but the system is definitely
more stable now.

[Venth]

Bob p, your post really helped me iron out installing Fedora, thank you so much. A little help for you, when installing updates, if you want to install with a yes conformation, type... yum -y update. The -y option will answer yes to the conformation to install, not requiring your input.

I myself was getting this mouse deadlock until i ran the command, yum update kmod-nvidia*.

This is what I found out. Boot Linux into run level 3 rather than 5 (X11). This is done by editing a file using the command, vi /etc/inittab, arrow down to the last line... id:5:initdefault:, press i, change 5 to 3, press Esc, press :wq, press Enter. Use the command, shutdown -r now, to boot into run level 3. Run, yum update. I then erased xorg-x11-drv-nouveau and all its dependencies using yum. This gave me a scrambled screen when trying to boot run level 5 from 3 using command, startx. I then Installed kmod-nvidia repository configuration files for yum, this let me use, yum install kmod-nvidia. I then installed a .run file I got from nvidia download using, ./NVIDIA-Linux-x86_64-260.19.36.run. This allowed me to get into X11 and I found my mouse would deadlock on me. Finally, I ran, yum update kmod-nvidia*, this updated one file. I then found x-screen-saver locking my screen while gaming, I disabled that.

I believe I was having a conflict somewhere with refresh rate settings. I don't know where, my guess would be, xscreensaver, Nvidia X Server Settings being used/applied and not saved to xorg.conf, or unchangeable Monitor Settings in LXRandR 0.1.1. I have removed xscreensaver and going to remove Monitor Settings Tool right now.

Another thing I have found out. I tried disabling a power saving feature that turns off my monitor by adding, apm=off acpi=off, to the /etc/grub.conf file. This gave me mouse deadlock.

The only other time I have gotten mouse deadlock is from Running VMware Player, installing Windows 7 inside WMware Player, and installing VMware Tools on top. This happens with running Windows or Linux.

This is how I was able to prevent deadlock under Fedora 14 LXDE. My online gaming and joining online chatrooms that use Adobe Flash 64bit, no longer give me deadlock. Thanks for the help all and best of luck.

As a final note: If you are filling brave, use the command, chkconfig, to see what is set to run on the different run levels. I absolutely love that command. Use, chkconfig --help, for further usage information.

Google is your best friend and dictionary. Use, define:deadlock. Learn it, live it, love it. That is all.

[bob p]

I have an Asus P7P55D motherboard. My problem was caused by the defective asus_atk0110 driver.

my problem was not in any way related to video. it turns out the ASUS driver that has a bug in it that causes delayed kb/mouse lockups under F14 / X11. i solved the problem by blacklisting the ASUS driver. switching back and forth between blacklisting/unblacklisting the driver has confirmed beyond the shadow of a doubt that the faulty driver was the source of the intermittent KB/mouse lockup problem.

/etc/modprobe.d/blacklist.conf:

blacklist asus_atk0110

it turns out that this driver lockup problem is well known to the driver package maintainer. you can find it with google. it seems no longer to be an issue in F15.