I'm having periodic freeze-ups (i.e., total system crash requiring manual powerdown) with Slackware. I get it with both 10.0 and Current. And I get it with both kernels 2.6.7 and 2.6.9.

My question: What are good troubleshooting steps to resolve this? Some kind of prose flowchart would be great.

My first thought was that it was mouse-related, but that might only be because the main symptom is cursor-freeze. I guess it could be all kinds of things.

One other possibility: I think I've always been using Firefox (0.93, 1.0PR and now 1.0RC1) when this has happened, but that might be a coincidence, since I'm very frequently using Firefox.

My system: IBM Thinkpad T21, 850MHz P3, 384Mb RAM, 60Gb hard drive, Microsoft cordless optical USB mouse in addition to built-in Trackpoint.

Thanks in advance for your help. This is now the only glitch in my otherwise smooth-as-silk setup.

Usually its a hardware conflict or faliure...

In my case, the two main reasons were gay ATI graphics drivers, and my Sata hard drive failing on me.

Start from low level, and move upwards.

Try just leaving it on, and not doing anything for a day... (preferebly, not even moving the mouse). then wawtch and see if it freezes

then make alot of read and write access to the hard drive and see if you get any crasehs..

move on to graphics.. some game of some sort..

etc...

Alan Cox publishes a kernel patch with fixes for the 2.6 kernel series. I do not have experiende with it, but knowing the quality of older -ac patches I think this could be the best choice. You can try it and if it doesn't work you always can throw it away.

Info on http://lwn.net/Articles/108005/

Thanks, xushi and rotvogel. Lazy bum that I am, I think I'll try the kernel patch first, then if that doesn't work, go through the process of elimination.

One question: I've got the latest Alan Cox kernel patch, but how do I apply it? And how do I protect my pre-patch kernel so I can revert to it if I want to?

I've done a couple of kernel compiles. Is the process essentially the same, or is this less involved?

Its more or less the same, yes.

I'm speaking for the 2.4 kernels, and it should be the same for the 2.6 series too. It would be something like
patch -p1 patchname.patch
but don't quote me on the exact syntax, as i've only patched a 2.4 kernel ages ago.

then recompile the usual way. Search LQ and you will find the exact syntax for it.

I don't think patch the kernel will fix your freez, it may fix it only with a deficient driver/module
which is updated by a corresponding patch (a patch that update code for the fautly module).

The original kernel is tested before go into final distribution, so modules should be fine without
patch but there can be exeption, who knows...

The main reason of freezing things as far I know may be related to bad RAM or bad graphic
driver. With BAD RAM, I mean realy bad ram chipset (hardware) or wrong software RAM usage
(wrong software code).

I would investigate with dmesg, the log files in /var/log to find where something goes wrong

If it were the ram (considering it would be "really bad ram"), then this problem should show up in the RAM test in post boot shouldn't it?

Granted there are RAM testing software out there thant can give us a definate answer =)

RAM test can be found at
http://www.memtest86.com/

It may be bad BIOS settings too, specially those about RAM latency etc..., AGP settings too

Go through the logs and see if you find errors.

Try to determine when those freezes happen.

I have experienced also some freezes like yours because I had an experimental feature turned on in my network driver. So rebuild your kernel and try to leave out the experimental stuff, although most of it is quite stable they are marked experimental for a reason.

Thanks, everyone, for these very good suggestions. I'm working through them now. Memory is fine, it turns out. I'm poring over the logs looking for something goofy. Good learning experience. I'll report back when I turn something up.

I feel like there must be a couple of logs that I'm not finding. I know most are in /var/log, but I'm pretty sure there are some screen messages that I haven't turned up in a log.

read /etc/syslog.conf to see where the logs go

Do you have a spare comp to try SSHing into your machine when it freezes?

Yes, I've got another PC on a LAN. I'll need to reinstall a simple Linux setup on it first.

When one machine is frozen, can you actually take a look at it from a peer machine? Sounds interesting.

clawhead, actually if it's really frozen you can't, but it actually sometimes happened to me that X hunged and I couldn't ctrl+alt nothing, but i could access from my other machine with ssh and kill X.