Problem: my desktop system hangs. Question: what to do next

[D. Hugh Redelmeier]

| From: Mel Wilson <mwilson-Ja3L+HSX0kI at public.gmane.org>

| I have a desktop system that can't get through a build of gdb-7.4.1
| without locking up the desktop, and, apparently, all other processing.

PC systems can go flakey so many ways.  They don't usually tell you
why.

Googling is great but your system's symptoms are so non-specific that
I cannot see it helping until you get something more.

I've fixed a small number of PCs -- I'm not a pro.

It is easy and cheap to run memtest86+ overnight and see what it sees.
Memory is the problem more often than one would think.  If it isn't the
problem, it is nice to know that too.  Memtest86+ seems to be a boot
option on my Ubuntu 10.04 system, so you don't have to look far to
find it.

There is a bunch of stuff to do temperature monitoring (lmsensors).
I've never figured it out and each motherboard has a slightly
different configuration.  It sounds as if it could be useful for you.

It is *really* handy to have spares to swap in and out to see if it
makes a difference

Power supplies fail for me more often than I'd expect.  Sometimes
subtly.  A spare power supply is nice to have.  I admit that it takes
an annoying amount of work to swap one.  So I put it off to well down
on my list of experiments.

My memory isn't what it used to be.  So I keep a lab book to record
details so that I can look back to see any pattern that forms.  Of
course it is hard to know what details are worth observing and
recording.

Can you do the problematic build, but switch (before the lockup) to
the old-fashioned text console?  There is a chance that kernel oopses
or panics might show up there (but be hidden by a normal X server).
There are also SysReq key combinations that do kernel diagnostic
things, best done from a text console.  See, for example,
<http://www.debian-administration.org/article/457/The_magic_sysreq_options_introduced>

Do tell us what you learn.  Experience is the best teacher; other
people's experience is cheaper than ones own.  Negative results
(non-results) are useful too, and are very much under-reported.

A P4 system isn't a great prize.  At some point it is better to cut
and run than solve a problem.  This should be especially obvious if
you are actually paying someone for the problem solving.  This is
advice that I ignore way too often.  Way, way too often.

Good luck!
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists