paulmd@efn.org wrote
> 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.

Still makes a lot more sense to check for bad caps and
bad power supply first, because bad memory should have
been obvious before the fault showed up, and if it wasnt,
you're going to need the longer run to see marginal memory.

And it isnt due to the memory going bad either,
it will be due to the motherboard not liking the
ram. It will work fine in a different system.

>>>>> 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.

Nope, no assumption what so ever. Just checking the
possibilitys that are likely to be uneconomic to fix first
so a minimum time is wasted on those systems which
are going to be discarded.

Its only worth checking jumpering if its very likely that
the system will be economic to repair and the fault has
been identified and you want to ensure that the system
setup properly once the fault has been identified and fixed.

>>> 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?

Not UNTIL the fault has been identified and fixed and you are
ensuring that there arent any other minor problems still extant.

>>>>> 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.

Minor dust wont see the cpu overheat when running that diag.

Yes, once the fault has been identified and fixed it is THEN
worth doing some checks that the system doesnt have any
other outstanding problems and the best way to do that is
to monitor the cpu temp while running something cpu intensive
to check the basics like whether the heatsink and fan have
been installed properly etc.

Pointless doing that until the fault has been identified and
its clear that the system is economic to fix and that the
owner isnt going to use the fault as a good excuse to
do what its been intending to do for a while now, just
replace the system with a new one, with someone else
needing to be convinced that the new system is justified etc.

> And Seatools DOES make demands on the CPU.

Like hell hit does cpu heating wise.

>>> 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.

No assumption what so ever. It doesnt happen.

> Bad form.

Pathetic excuse for mindless bullshit.

>>>>> 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.

Like hell it does.

> You can spot slighter bulges, when they're clean.

Mindlessly silly.

>>> 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.

You're wrong. The vast bulk of what is claimed to be bad ram is ram
that that motherboard doenst like much or which the motherboard hasnt
been configured for properly and which works fine in a different system.

>>>>> 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.

Never ever could bullshit its way out of a wet paper bag.

Nothing half arsed about initially assuming that the user isnt
a fool and only checking something like that if it looks like the
system is fine and the problem is just that the user didnt wait
long enough. When it spontaneously reboots and chkdsk locks
up, its MUCH more likely that the diag is locking up too.

AND you dont gain a damned thing by proving that the user
didnt wait long enough with the diag if its still locking up when
chkdsk is run and its still spontaneously rebooting anyway.

Its an irrelevant detail of no significance what so ever.

>> 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.

Pity you never said that initially, just now when your nose has
been rubbed in your terminally stupid approach to fault finding.

>>>> 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.

Not in the particular case being discussed.

> 2) Small (but not zero) chace of rendering the computer
> non-bootable. Not something to do "just because".

Pity you said you do that anyway with this particular motherboard.

Cant even manage a consistent line in mindless bullshit.

> I don't want to have to tell a cuntomer that i accidently toasted the BIOS.

Pity you said you do that anyway with this particular motherboard.

Cant even manage a consistent line in mindless bullshit.

> You have GOT to have good ram to do
> a bios flash, or you're taking a big risk.

Bullshit.

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

> I argree, which is why it's low on the list.

Shouldnt even be on the list at all with that set of symptoms
unless every other possibility has been carefully eliminated
and the only alternative is to discard the system or replace
the motherboard.

>>> 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.

Mindlessly silly with normal dust levels.

>>> 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.

Like hell I did, I read what you posted to the OP.

Not a shred of assumption involved whatever.

> That's a bad trait in a supposed technician.

Having fun thrashing that straw man are you child ?

> And a constant failure of yours: assumptions.

Not a single assumption what so ever.

Just your pathetic excuse for bullshit/lies.

>>> 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.

Yep.

> Machine is already off, time is wasted powering up a machine
> to check for logs, when there is an inspection to complete.

Mindlessly silly when the event logs are very likely to have useful
information in them and should have been checked first anyway.

> It takes only seconds, thirty at most. Booting can
> take minutes. In due time the machine will be booted.

Makes a hell of a lot more sense to boot the system first
before even bothering to open it to check the event logs.

>> 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.

Taint lost a thing if the system performs fine in that config.

> We can get to windows to check that shit AFTER.

Anyone with a clue does that first with those symptoms,
after the event logs and a check for bad caps.

>> 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.

Not a shred of evidence of any problem with any hard drives.

Even someone as stupid as you should have noticed that
the symptoms didnt change with two different hard drives.

>>> 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.

Wrong. Its a hell of a lot easier to check for fans spinning.

> As long as they're checked before it's booted into Windows.

Mindlessly silly. Thats what should be done first.

>>> 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.

Pity you claimed they need to be dealt with. Not necessarily.

>>> 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.

Pity the OP didnt say that. And that is why the system should
be booted first, to see what the freeze and hang rate is.

> You can wait hours for something to happen.

Pointless if the boot logs dont indicate anything useful and
the system worked fine while they were being inspected.

Makes a hell of a lot more sense to check for
bad caps next if the event logs arent useful.

> If you're gonna spend hours waiting,

Only a fool would be stupid enough to do that.

> you may as well spend it on something productive.

Pointless wasting your time on jumpers and ribbon
cables at that stage with a fault that is rarely seen.

The other real possibilitys should be elimated first,
particularly a quick check for bad caps because it
wont usually be economic to do anything more to
the system if its got bad caps.

>>> 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.

Pointless testing the sound system too when
changing the drive made no difference.

> Otherwise, it's being half assed.

Crap, yours is a completely stupid way to fault find
when another drive makes no difference and there
isnt a shred of evidence of any hard drive fault.

>> 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.

Nope, not a single assumption what so ever involved.

Just understanding what can cause particular symptoms.

> It's not efficency, it's plain laziness and willful neglect.

Thanks for that completely superfluous proof that you wouldnt know
what effective fault finding was about if it bit you on your lard arse.

No surprise that no one is actually stupid enough
to employ you to fault find commercially.

>>> 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.

Nope, not when the fault cant be due to bad caps.

> You can save a 2+ hour virus removal
> project, if you would just open up the case.

You dont even need to open the case at all
if the event logs identify a software problem.

>>> 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?

Yep. And I dont waste time on systems that are going to be discarded.
When most faults that arent fixed by a power supply fault get discarded
if they are a hardware problem, its important to work out whether its
going to be economic to fix first. And that means working out whether
its actually a hardware problem at all first, and then whether its going
to be economic to fix next. Its only worth checking the other stuff like
the jumpers and cables and whether the heatsink is installed properly
etc once the fault has been identified and fixed and the system will
be returned to the owner.