Complete Freeze 8.1 RELEASE (KDE/Gnome)

Hello,

Hopefully this is the correct place to post this. In the last two days I have had two complete freezes of the desktop while running KDE 4.5.1 on 8.1 Release. I had upgraded shortly before leaving town to 4.5.1 from 4.4, so I have not been using it much until this week. I never had such freezes previously. It has only happened thus far with Dolphin open (I see others have reported crashes with Dolphin), but I am completely unsure if it is involved.

During the freeze the keyboard and mouse become unresponsive and the screens do not change. I must do a hard reboot to get the machine back. I have tried to ssh into the machine during these freezes, but I get a timeout. I am running a 24-core machine and am surprised this happens.

How can I further investigate the cause of this freeze? Anyone else with similar experience? I am using the nvidia driver.

Thanks,
 
It honestly sounds like a bug with the nvidia driver. Software running in userspace (such as KDE) isn't going cause a completely system crash, like this, only software running in the kernel should (such as the driver). Does it happen if you run with the 'nv' or 'vesa' driver?

Adam
 
Thanks, I agree with you. I just upgraded the Nvidia driver to the latest version and will see if this happens again. It's just that it never happened with the same Nvidia driver and KDE4.4.x and 8.0-p2.

Is there a log file that may help suggest what caused the freeze?

aric
 
I have the same problem on two boxes running two different versions of Linux. One Arch Linux and the other Ubuntu 10.10. Both just freeze solid, though I don't run dolphin, it doesn't seem to matter what programs are running, they just freeze; leaving me to believe it's a KDE 4.5 bug, though both machines are running nvidia drivers, it still smells like a KDE issue, since I too have been using the same driver on the Arch Linux machine before upgrading to this latest version of KDE, which is version 4.5.2. Not sure what the current version of KDE is on Ubuntu 10.10 and that machine's at work, but their packages site says kdebase-runtime (4:4.5.1-0ubuntu3).
 
KDE4 may be triggering the crash, but there is clearly a bug in the kernel or the drivers (and my bet would be the drivers).

Unfortunately, I do not know of anyway of debugging this short of checking /var/crash for a kernel core file and/or setting up a serial console.

Adam
 
There is nothing in /var/crash on my machine. I can look into setting up a serial console, if that is possible on my machine.

I have to agree that the new KDE is intimately involved with the problem, as everything else is the same and I had not experienced the problem in the preceding 6 months with older KDE versions.

Aric
 
I used to experience the same sort of freezes with 8.1 64 bit and Nvidia and KDE 4.5.1. If it is any encouragement to you, I am now using 9-current with Nvidia and KDE 4.5.2 and the problem has disappeared. I only had the issue when the earlier system was running under very heavy load or sometimes xscreensaver would freeze. In the earlier system, I uninstalled xscreensaver and this eliminated unattended freezes. KDE 4 is evolving and I believe that this is the culprit. I tried 8.1 with nv and KDE 4.5.1 and hit the same freezes.
 
It just happened again, with the new Nvidia driver, 8.1-Release and KDE 4.5.2. Now my machine has never been under heavy use when this happens. Again, I cannot find any sort of crash log or log file mentioning the freeze. Not sure how we can try to diagnose the problem.

How long have you been crash-free on 9-current? I hate upgrade to that as other stability issues may arise and the problem is intermittent on my machine (uptime was 4 or 5 days this time). If this continues, I'll move to another window manager and see if it still happens. I will try to reboot with the nv module instead of Nvidia, but if I remember right there were screen issues with it and I may not be able to run it long enough to see the freeze (i.e., need to get work done).
 
Does this happen when you are working or when the screensaver kicks in? Just as an experiment, you may want to uninstall xscreensaver and see if the problem goes away. I have not had any freezes in a long time and the key seemed to be the attempt for either the screensaver to kick in or power saving to kick in.
 
For me, it's hard to say, because my freezes already occur when the screensaver is on and I'm nowhere near either machine when the freeze occurs. Though I'm using kscreensaver, not xscreensaver; A Friend of mine at work was having the same issue with Fedora 13 and he says it was very prone to freezing and to him it seemed like it was when the screensaver was attempting to engage. It should be noted he was on a laptop, so power management is extremely likely. I'll try turning off 'Power Devil' in System Settings on my Arch Linux system. (Sorry, I don't use FreeBSD as my desktop, I've multiple servers that I run FreeBSD exclusively, though in this case, it doesn't probably matter much since, the exact same problem happens on multiple versions of Linux too..)
 
Gnome/X hangs

Hi,

I'm using Gnome on 8.1 RELEASE 64-bit using the NVIDIA driver and my X hangs at random intervals, sometimes a few weeks sometimes a few days. GDM won't restart, X won't let itself be killed and consume 100% of the CPU. If I go to a tty the console has garbled text. I can however send SIGSTOP to Xorg and that seems to calm things a bit.. but I'm still left in an unusable state.

I've also consistently seen "polkit-gnome-authen" experience core dumps. I searched online and some bug was filed (http://www.freebsd.org/cgi/query-pr.cgi?pr=148272) but I'm not sure if that is related. I rebooted and my system is now hung on the NVIDIA logo; previously it hung while the screensaver had activated.

I'm not sure what /var/crash is but this is what mine has:
Code:
[root@spock ~]# ls /var/crash
minfree
[root@spock ~]# cat /var/crash/minfree 
2048

My dmesg, truncated:
Code:
[root@spock ~]# dmesg | egrep -i \(nvidia\|nv\) | grep -vi mcp55
  TSC: P-state invariant
ACPI APIC Table: <Nvidia ASUSACPI>
acpi0: <Nvidia ASUSACPI> on motherboard
nvidia0: <GeForce 8600 GT> on vgapci0
vgapci0: child nvidia0 requested pci_enable_busmaster
vgapci0: child nvidia0 requested pci_enable_io
vgapci0: child nvidia0 requested pci_enable_io
nvidia0: [ITHREAD]
ugen0.1: <nVidia> at usbus0
uhub0: <nVidia OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
ugen1.1: <nVidia> at usbus1
uhub1: <nVidia EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
NVRM: Xid (0001:00): 8, Channel 0000007e
NVRM: Xid (0001:00): 8, Channel 00000001
NVRM: Xid (0001:00): 9, Channel 0000007e Instance 00000000 Intr 00000010
NVRM: Xid (0001:00): 9, Channel 0000007e Instance 00000000 Intr 00000010
NVRM: Xid (0001:00): 12, Ch 0000007e Cl 00000030 Off 00000104 Data 00000000
NVRM: Xid (0001:00): 9, Channel 0000007e Instance 00000000 Intr 00000010
NVRM: Xid (0001:00): 12, Ch 0000007e Cl 00000030 Off 00000100 Data 00000000
NVRM: Xid (0001:00): 12, Ch 0000007e Cl 00000030 Off 00000104 Data 00000000

I have a hunch it is the driver.

-Alex
 
Moved the topic up one forum to include experiences with multiple WMs.
 
I think I may have discovered why my system was freezing in the GUI. My video card began displaying artifacts all over my screen even during BIOS POST just after rebooting on the last lockup. The monitor is fine as I am able to connect it to my laptop.

A new video card is on the way, hopefully that fixes this issue at least on my part. Perhaps whoever is also having issues might benefit from trying out another video card? Mine was 3 years old.

-Alex
 
Same Thing, Other Side

I'm experiencing the same issue in my latest installation of FreeBSD 8.1 except that I am not using an nvidia card (or driver) on my system. The video card is an onboard (ATI Radeon 3000) and the problem has occured in both i386 and amd64 versions of FreeBSD 8.1 now. It did happen once, during xscreensaver although I agree it is not limited to the screensaver itself. I'm using fluxbox on xorg so no KDE components to speak of here.

I'm inclined to say that this issue may be due to ACPI settings or maybe even a GENERIC kernel attempting to use today's hardware. IDE vs SATA for example. I've seen issues like this in the past where the OS attempts to communicate with the hard drive using incorrect read/write modes and causes the system to lock up which may account for poor log files being written during a crash.

Anyways, just my two-bits. Hope it helps.
 
@t1m1976 the only problem I have with that theory is, it's happening exactly as described on 3 separate distros of Linux too, Ubuntu 10.10, Arch Linux, and Fedora 13/14. I was having the problem every day on my Arch Linux system, I ran some updates one day couple weeks back, and a handful of Xorg packages updated ( Mostly libx* stuff ) and the freezes have subsided considerably, but do still occur. I suppose ACPI could be involved, *shrug* but it smells alot like an X issue now. Switching from KDE's screensaver to XScreensaver has helped a little too, but again, not by much.
 
@jnbek, I can not boot into FreeBSD with ACPI disabled to further test the issue on my system. I did not stop and look at why, but the result was kernel trap and reboot in fifteen seconds. I suppose I could rebuild the kernel without it and I might just do that, if that is safe. All I can really offer is that I'm using ATI/Radeon products here and I occasionally have the same problem, (once while watching xscreensaver during 'galaxy' mode and once while just sitting on FluxBox-1.1.1 with only XMMS-1.2.11, GKRellm2 and Firefox3.5 open on the same window). I agree, with all the different distributions you are running, this does not sound like anything related to a disk-specific issue. I am still leaning towards the ACPI because of how something like that can control a system but that does seem strange since it happens both when the system is in use and left alone. I agree with you it seems like a graphics issue and/or something in the Xorg7 server against the hardware. I would be interested in finally seeing this issue resolved or at least explained so I will be watching this thread. I will be buying a new video card next month so it will be interesting to see if it still happens after that.
 
Hey, which nVidia Graphics card are you using? I was having similar problems with my NVIDIA GeForce 8800. If you have the same one, please help me fix this too!
 
Same thing happens in Slackware 13.1 I see. In fact, it happened almost immediately after starting xscreensaver during the atlantis mode. I was, again, using fluxbox. The interesting part was that I was not using the ati or radeon driver this time. I wish I knew more about *nix libs so that I could further the conversation more intelligently. I'm going to keep searching other threads and other forums in an attempt to discover any information possible. I'm just hoping it is not limited to certain hardware. I'm about to test Slackware 13.1 with my wife's computer and her nVidia PCI-e card soon. I wonder if it will happen there as well.
 
It seems the problem will vanish when using vesa driver or disabling DRI for xorg. This is my last post on this thread. I feel I have discovered, through research, what causes this issue. All I can do now, as typical end-user, is buy a new video card and cross my fingers, wait for them to fix the bug, or continue without DRI enabled.
 
I recently ran an update on my Arch Linux system, a dozen or so X libs, a new nvidia driver and some assorted KDE packages were upgraded. I believe DRI was also upgraded as well. This has been ~4 days and I'm not had issues yet. So, I say cross the fingers run a csup on the ports tree and a portupgrade -facv and see how it goes. So far we've kind of been able to eliminate nVidia driver, since a user above with an ATI card has reported the same problem, screensaver seems to be eliminated, since it doesn't matter if you're using KDE screensaver, Gnome Screensaver or even Xscreensaver, this also eliminated KDE as GNOME users are reporting it. So we're getting down to the meat and potatoes, the X libraries, DRI, Mesa maybe? or ACPI, to eliminated ACPI, we should consider the implementation differences between *BSD and *Linux, if there are any, what similarities they share and if those similarities could be a trigger; I wish I could get FreeBSD to work perfectly with my MS Ergo 4000 keyboard, as a programmer, I use all it's keys and can map all but the Zoom in Linux, but BSD doesn't seem to acknowledge the top row of 'special' keys that I've come to reply on, otherwise I'd be using FreeBSD as my exclusive desktop AND server environment. I just don't have a spare system to use for testing this bug and it's possible differences on any other system; However I'm getting to be pretty confident we're narrowing this down to X and it's ancillary libraries.
 
Hi,

I am also experiencing system freeze these days on a box (x86) where I recently installed the 8.1 Release, the latest available nvidia drivers, gnome2 and some more 350 packages...

Freeze occur randomly, the last of them occured while I was playing with audacious. The day before it happenned while I was viewing this exact thread
which is kinda ironic.

I don't know what triggers these freezes (no dump, no log, nothing...) but to let you know: DRI is enabled, ACPI is not, VESA is. I am thinking about any other detail that matters but I don't find any.

The version of nvidia drivers I ran is 260.19.29 though the latest port version is 256.53. At time of installation, I downloaded that same driver version from the nvidia website, did the make makesum trick to update the port structure so that it could compile and it did.

Since I am using, theoritically, the upcoming port version, I am wondering whether it remains a driver issue or if it's something else.

As the new driver release didnt solve the issue, I am thinking of downgrading
to the current port version to see if it hangs the same way even if it's probably a bit useless.

Did any of you make some progress ?

E.S
 
It seems most are not having the issue, it appears that dri may have been the culprit, but there exists no concrete evidence to support this. I am no longer experiencing the issue on any of my Linux boxes and I assume others in this thread are also not experiencing the issue either. My advise is to try with DRI off, or upgrade you DRI packages and see if that helps.
 
Back
Top