Rod Speed wrote:
> paulmd@efn.org wrote:
>
> > Currently my top theories are bad caps,
>
> Yes, that can produce the symptoms he is seeing.
>
> > jumpers,
>
> Doesnt produce the symptoms he is seeing.
>
> > bad RAM,
>
> Unlikely to have just started to produce those symptoms.

I must disagree. But in any case, it needs to be tested.
>
> > and bad IDE controller.
>
> Doesnt produce that reboot effect.
>
> > But ALL possibilties need to be checked
> > and eliminated before a diagnosis is made.
>
> Effective debugging is done by concentrating on the possibilitys
> that can produce the symptoms seen, not wasting time on
> possibilitys that dont produce the symptoms seen.

But leaving problems is bad form, and, they ARE problems.
>
> > Bad or Wrong cable is also on the list.
>
> Nope, that wont produce the reboot effect either.
>
> > Little hardware problems that you don't think are the issue, often are.
>
> Only if you dont actually have a clue about
> what can produce particular symptoms.

No, whether or not you think they can produce symptoms. What one
computer may be fine with, another may choke on. For example, some
newish dells actually require the cable select position, and just
aren't happy with master/slave.

>
> > They need to be addressed, and eliminated.
>
> Not when the actual fault is elsewhere.
>
> > At a minimum, They interfere with a proper diagnosis,
>
> No they dont with symptoms like those seen.
>
> > and they need to be fixed anyway, so no reason not to fix them.
>
> Waste of time considering them until the fault is
> found and you decide if the repair is economic.
>
> If for example it is a bad motherboard, the owner may well
> just prefer to buy a new system and move the drive contents
> to the new system, and may not even want to have the old
> drive in the new system, so minor config problems are irrelevant.

Lets say he gets a new board, and plops it into his old case,
misconfiguartions and all. The old problems resurface, lazarus-like. Or
a strange new set. All due to the stuff you dismissed as irrelivant.



>
> > And, well the other issues caused by them go away,
> > so all around a better way of doing things.
>
> Nope, particularly when its quite likely that the motherboard
> is bad and that the owner will choose to buy a new system.
>
> > Dust, and associated heat issues, for example may
> > cause an occasional freeze, and random reset.
>
> Not with the seagate diag.

Sure they can. With *any* program, windows, linux, dos or otherwise. If
the hardware is faulty, the symptoms will always be the same. No
progarm is immune to basic stuff like that.


>
> > So do bad caps
>
> Yes, but if those are bad, there isnt any point in mindlessly
> cleaning out the dust, swapping the cables, etc etc etc, if
> the owner is likely to buy a new system if it does have bad caps.
>

Of course not, but cleaning out the dust first makes bad caps easier to
see. And if the caps are so bad, that you can see right away before you
turn on the compresser..... you can of course stop there. And ask the
user what they want to do.

> > and bad ram.
>
> Ram doesnt usually go bad.

I've seen enough Bad ram to entirely disagree. It's real common.

>
> > Start by fixing problem 1, and continue on until all the issues are fixed.
>
> Makes a lot more sense to first decide if the caps are bad
> and dont bother with anything else if the owner decides to
> buy a new system because the caps are bad and that its
> a good reason to upgrade to a new system now.
>
> > Every fan works, and every last thing is configured
> > to spec. That way there aren't lingering doubts.
>
> Stupidly inefficient way to diagnose a fault like that one.

Thorough.
>
> > As for why is the diagnostic hangin? Seatools says, right while
> > it's loading that certian types of hard drive problems may cause
> > a hang (for several minutes). And please be patient. It will
> > continue eventually. It disables the mouse during tests, too.
>
> So the OP is likely to have seen that and waited long enough.

He didn't say so, therefore we can't assume.
>
> Much more likely that there is a serious hardware
> problem like bad caps or a flakey power supply.
>
> > There is one last thing to try, which is a bios upgrade.
> > Bios upgrades often address hardware incompatibilties.
>
> They dont just show up after the system has been working fine.

They can if new hardware is added to the mix we haven't been told
about.
>
> > But all other possibilities need to be eliminated first.
>
> Wrong again. It can be the best thing to try if there is some
> obvious hardware incompat.

Most hardware incompatibilites aren't obvious, and the changelogs on
bioses are often very vauge. Sometimes nonexistant. I normally do bios
upgrades anyway, at least on some of the better systems, like Dell,
where it can be done with mimimal time and risk, and a high degree of
certianty you got the right bios. Some boards I avoid bios upgrades on,
like Pcchips, as they aren't very good about listing all of their
boards, and you can get the wrong bios too easily.

> No need to clean the dust out first.

Yes there is, I always do just so my hands don't get icky. And it aids
with visual inspection. And it may just fix a heat problem.

My usual routine goes, open up the case, take an air compressor to it
if it needs it. Then look at the caps. If bad: issue identified. Ask
whether user wants a new motherboard or a new system.

If caps appear good, then continue on to the rest of the system: do
drives have the correct cables and jumper settings? If no, rearrange to
proper config.

Then power it up, do all the fans run? At least PSU fan, CPU fan, and
Northbridge and video card fan? These are sources of instability.
Failures of these key fans must be addressed to prevent further damage
to system. Case fans can be dealt with later. But they need to be dealt
with. Evenually.

Boot it up, to see it it's any obvious virus or windows problem.

Then sic diagnostic software on it: if it comes with a utility
partition with diagnostics, run it on the most thorough settings. (fix
other computers in meantime), check for heat issues whilst running
every so often.

If no onboard diagnostic partition, or only a limited set, the old
standbys of memtest will do, and I've come to really like MHDD (thanks
to Alan for pointing it out).

There are variations to this basic pattern, of course. Depending on
user complaints of symptoms. But I always do the basic visual
inspection, as very often the user has problems they didn't tell you
about. They usually tell you about the 1 or 2 most annoying. They
figure they can live with the rest, or figure they don't want to scare
you off with a giant laundry list. (I've seen giant laundry lists from
time to time, though :) )