Rod Speed wrote:
> paulmd@efn.org wrote
> > 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.
>
> Your problem.
>
> > But in any case, it needs to be tested.
>
> Nope, not until the more likely possibilitys like bad caps are
> checked for first, particularly as its one of the slower checks.

A complete check takes a long while indeed. But in over 90% of the
cases, if the ram is bad, it will be obvious within 5 minutes. Often
times, i do abort the test early.
>
> >>> 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,
>
> Not when the system is about to be discarded
> because the motherboard caps have gone bad
> and the owner has chosen to buy a new system.
>
> Anyone with a clue just moves the data from the
> system with a fault to the new system and discards
> the system which has that serious a fault.

Assumptions again.
>
> > and, they ARE problems.
>
> You aint established that that system actually has any other problem.

If I don't check, I never will. You see the problem?

>
> >>> 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,
>
> Fraid so.
>
> > whether or not you think they can produce symptoms.
>
> I KNOW that a bad cable and incorrect jumpering
> cant produce that reboot effect the OP is seeing.
>
> > What one computer may be fine with, another may choke on.
>
> Mindless waffle with that particular symptom.
>
> > For example, some newish dells actually require the cable
> > select position, and just aren't happy with master/slave.
>
> STILL doesnt produce that REBOOT EFFECT, and
> that wont produce a fault that shows up later either.
>
> >>> 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.
>
> Not even worth considering UNTIL he
> has decided to replace the motherboard.
>
> > The old problems resurface, lazarus-like.
>
> Wont happen if bad caps can be seen on the original motherboard.
>
> > Or a strange new set. All due to
> > the stuff you dismissed as irrelivant.
>
> I didnt do that, I JUST SAID THAT THEY WONT
> PRODUCE THE SYMPTOMS HE IS SEEING.
>
> >>> 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.
>
> Nope.
>
> > With *any* program, windows, linux, dos or otherwise.
>
> Wrong with stuff that makes few demands of the cpu.

Sorry, but just because an application isn't CPU intensive does NOT
mean the CPU won't overheat. And Seatools DOES make demands on the CPU.

>
> > If the hardware is faulty, the symptoms will always be
> > the same. No progarm is immune to basic stuff like that.
>
> If there is JUST a bad cable, any decent diag wont just lock up.

Assumptions again. Bad form.
>
> >>> 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.
>
> Bullshit. You dont get much dust accumulating on the tops of the caps.

It accumulates heaviest on fans, and heatsinks to be sure. But believe
me, it does accumpulate on caps and every other place too. You can spot
slighter bulges, when they're clean.

>
> > 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.
>
> With the symptoms seen, no point in bothering with any
> compressor, the only thing that makes any sense at all
> is to check for bad caps and if there bad caps, ask the
> owner what they want to do about that, because there
> is no point what so ever in checking anything at all if
> they just want to buy a new system and have the data
> moved over from the old system.
>
> > 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.
>
> Pigs arse it is.

I've seen lots.
>
> >>> 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.
>
> Stupidly inefficient and a complete waste of time when
> the owner will normally decide to buy a new system
> with a fault like that thats uneconomic to repair.


>
> >>> 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.
>
> Corse you can if you actually have a clue about efficient debugging.


Efficient? Half-assed is closer.
>
> Only when there is no obvious problem like bad
> caps does it make any sense to actually try running
> it yourself to see if the owner got confused there.
>
> AFTER you have checked the event log to see
> if that has any useful information on the reboots.
>
> Essentially because its very unlikely indeed to be a
> bad hard drive when the OP got the same systems
> with two different hard drives, so the hard drive diag
> is WAY down the list of what is worth trying if you
> havent identified where the problem is.

Hence: visual inspect first.
>
> >> 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.
>
> Its normally obvious enough if thats been added recently.
>
> And if the caps look fine, it makes much more sense if the
> event log doesnt show anything useful to see if the reboots
> still happen with an absolute minimum of hardware than it
> ever does to fart around checking jumpers and cables
> which arent going to produce the symptoms seen.
>
> Because if the reboots still happen with a bare minimum
> of hardware, its very likely that the system will be discarded
> so that other crap is likely to be a complete waste of time.
>
> >>> 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,
>
> Which is why anyone with a clue sees if the fault
> remains with an absolute bare minimum of hardware.
>
> > and the changelogs on bioses are often
> > very vauge. Sometimes nonexistant.
>
> Sure, but thats an separate issue to your silly claim that
> all the other possibilitys need to be eliminated first.

I put this last for more than 1 reason:

1) It's a pain in the ass to get the proper bios in a lot of cases.
2) Small (but not zero) chace of rendering the computer non-bootable.
Not something to do "just because". I don't want to have to tell a
cuntomer that i accidently toasted the BIOS. You have GOT to have good
ram to do a bios flash, or you're taking a big risk.



>
> Its usually pretty obvious what can be a bios problem.

I argree, which is why it's low on the list.
>
> > 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.
>
> Sure, but thats an separate issue to your silly claim that
> all the other possibilitys need to be eliminated first.
>
> Its usually pretty obvious what can be a bios problem.
>
> >> No need to clean the dust out first.
>
> > Yes there is, I always do just so my hands don't get icky.
>
> Your neurotic hangups are your problem.
>
> > And it aids with visual inspection.
>
> Dont need to do that BEFORE FLASHING THE BIOS.
>
> > And it may just fix a heat problem.
>
> Dont need to do that BEFORE FLASHING THE BIOS.

Yes I do, Bios flashing is not something to take lightly. You want to
maximise the chance of sucess by mimising potential for bad outcome.
>
> > 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.
>
> Nothing like your original, you're flagrantly dishonestly slithering
> off to somewhere completely different now after your nose has
> been rubbed in the terminal stupidity of your original claims.

I didn't tell you my usual method before. You assumed. That's a bad
trait in a supposed technician. And a constant failure of yours:
assumptions.

>
> > If caps appear good, then continue on to the rest of the
> > system: do drives have the correct cables and jumper settings?
>
> Makes a hell of a lot more sense to check the event logs first in this case.

No. Machine is already off, time is wasted powering up a machine to
check for logs, when there is an inspection to complete. It takes only
seconds, thirty at most. Booting can take minutes. In due time the
machine will be booted.

>
> And to see what the minimal config does reboot wise
> next if the event logs dont have anything useful in them.

Another reboot cycle lost. We can get to windows to check that shit
AFTER.
>
> And then try swapping the power supply next.

That's a good thing to try at some point, but, the problem is with the
hard drives, concetrate there first.

>
> > If no, rearrange to proper config.
>
> Waste of time with the symptoms seen.
>
> > 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.
>
> This stuff should be checked before the jumpers too.

Not a GREAT deal difference here. As long as they're checked before
it's booted into Windows.
>
> > 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.
>
> Not necessarily, most obviously when they arent necessary.

A detemination to make later.
>
> > 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.
>
> Makes a lot more sense to see if the
> minimal config still exhibits the problem first.

Not yet. Especially for very occasional freezes and hangs. You can wait
hours for something to happen. If you're gonna spend hours waiting, you
may as well spend it on something productive.

>
> > 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).
>
> It wont be a hard drive problem, because he gets
> the same result with two different hard drives.

You can't eliminate hard drive failure until you actually test the hard
drives. Otherwise, it's being half assed.
>
> And its stupid having a mindless sequence regardless of the
> fault seen, grossly inefficient way to diagnose systems.
>
> > There are variations to this basic pattern, of course.
> > Depending on user complaints of symptoms.
>
> Stupid checking the jumpers first with the reported symptoms,
> because they cant be the problem. Ribbon cable too.

Assumptions again. It's not efficency, it's plain laziness and willful
neglect.
>
> > 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.
>
> Thats only worth doing AFTER the fault has been
> fixed and is become clear that its economic to fix.

Since visual inspection IDENTIFIES the most common non-economical
fault: bad caps, it's worth always doing first. You can save a 2+ hour
virus removal project, if you would just open up the case.


>
> > 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 :) )
>
> Irrelevant to efficient fault finding.

My computers STAY fixed, do yours?