Is my drive dead?

[zzzzara]

Hi,

I've had a strange problem for a while, with Windows resetting
occasionally without warning. Most of the time it works fine. I ran
chkdsk /4, and got stuck at 11% of stage 4. It does the same if I boot
from my spare hard drive, so I guess it can't be a software problem.
The seagate diagnostic tools (run from a boot CD) hang as soon as they
start the quick or the full disc check.

Seems fairly clear there's a hardware problem. Before I get a
replacement drive... is there a way to check that it is the drive at
fault and not the controller/motherboard? Some more sophisticated
diagnostic software, perhaps?

(Ideally I'd test the drive in another PC, but I don't really have
access to one.)

The drive is a SATA Barracuda 7200.8 and the motherboard Asus A8V.

thank you for your time!

 

[Rod Speed]

Probably not.

(e-mail address removed) wrote

I've had a strange problem for a while, with Windows resetting
occasionally without warning. Most of the time it works fine.

You dont normally get that with a bad hard drive.

I ran chkdsk /4, and got stuck at 11% of stage 4.
It does the same if I boot from my spare hard drive,
so I guess it can't be a software problem.

Yes, but its also unlikely to be a bad hard drive too.

The seagate diagnostic tools (run from a boot CD) hang
as soon as they start the quick or the full disc check.

Seems fairly clear there's a hardware problem.
Yes.

Before I get a replacement drive...

Its unlikely to be a bad hard drive if you get the
same problem with two different hard drives.

is there a way to check that it is the drive at fault
and not the controller/motherboard? Some more
sophisticated diagnostic software, perhaps?

Yes, check the event log and see what Win says about
why you are getting reboots if you are running 2K or XP.

(Ideally I'd test the drive in another PC,
but I don't really have access to one.)

OK, post the Everest SMART data for the drives.
http://www.majorgeeks.com/download.php?det=4181

 

[paulmd]

Hi,

I've had a strange problem for a while, with Windows resetting
occasionally without warning. Most of the time it works fine. I ran
chkdsk /4, and got stuck at 11% of stage 4. It does the same if I boot
from my spare hard drive, so I guess it can't be a software problem.
The seagate diagnostic tools (run from a boot CD) hang as soon as they
start the quick or the full disc check.

Seems fairly clear there's a hardware problem. Before I get a
replacement drive... is there a way to check that it is the drive at
fault and not the controller/motherboard? Some more sophisticated
diagnostic software, perhaps?

(Ideally I'd test the drive in another PC, but I don't really have
access to one.)

The drive is a SATA Barracuda 7200.8 and the motherboard Asus A8V.

thank you for your time!

I'm thinking most likely jumper settings are at fault. Somethimes wrong
jumper settings like having 2 masters actually kinda sorta tries to
work, instead of the more usual: "you have dirves on this cable?
Really?".

Check to make sure everything is Kosher, as far as jumper settings go.
Master on the end of the cable, slave on the middle. If you use cable
select, it's all devices on the cable, or none of them.

Another posiblilty is bad cables themselves, though it's rare. Double
and triple check to see that everything is properly seated. Yet another
is bad ide controller. It's also possible to have TWO bad drives. Alas.

Since you've got the case open, check your motherboard for bad
capacitors (little soda cans), if any are bulging or leaking, they're
bad.

And blow out the dust, it's probably not your problem, but it's a
routine maintanence thing to be done anyway.

Download and run memtest86+ from www.memtest.org to check RAM.

A very powerful diagnostic is MHDD, use it as a boot CD. Ignore
anvanced features, just hit f4 twice to run a scan.

http://hddguru.com/content/en/software/2005.10.02-MHDD/

 

[Rod Speed]

(e-mail address removed) wrote

(e-mail address removed) wrote

I'm thinking most likely jumper settings are at fault.

Doesnt produce the symptom seen.

Somethimes wrong jumper settings like having
2 masters actually kinda sorta tries to work,

Yes, plenty of drives work fine with bad jumpering.

instead of the more usual: "you have dirves on this cable? Really?".

Check to make sure everything is Kosher, as far as jumper
settings go. Master on the end of the cable, slave on the middle.

That wont produce that symptom either if its not done like that.

If you use cable select, it's all devices on the cable, or none of them.
Ditto.

Another posiblilty is bad cables themselves, though it's rare.

Very rare indeed for that to produce spontaneous reboots.

The diag freezing in spades.

Double and triple check to see that everything is
properly seated. Yet another is bad ide controller.
It's also possible to have TWO bad drives. Alas.

A bad drive wont produce spontaneous reboots, or the diag freezing,
and its very unlikely indeed to have two drives producing that effect.

Since you've got the case open, check your motherboard for bad
capacitors (little soda cans), if any are bulging or leaking, they're bad.

And blow out the dust, it's probably not your problem,

Certainly not with the diag freezing.

but it's a routine maintanence thing to be done anyway.

Download and run memtest86+ from www.memtest.org to check RAM.

 

[paulmd]

Currently my top theories are bad caps, jumpers, bad RAM, and bad IDE
controller. But ALL possibilties need to be checked and eliminated
before a diagnosis is made. Bad or Wrong cable is also on the list.

Little hardware problems that you don't think are the issue, often are.
They need to be addressed, and eliminated. At a minimum, They interfere
with a proper diagnosis, and they need to be fixed anyway, so no reason
not to fix them. And, well the other issues caused by them go away, so
all around a better way of doing things.

Dust, and associated heat issues, for example may cause an occasional
freeze, and random reset. So do bad caps and bad ram. Start by fixing
problem 1, and continue on until all the issues are fixed. Every fan
works, and every last thing is configured to spec. That way there
aren't lingering doubts.

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.

There is one last thing to try, which is a bios upgrade. Bios upgrades
often address hardware incompatibilties. But all other possibilities
need to be eliminated first.

 

[Rod Speed]

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.

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.

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.

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.

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.

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.

and bad ram.

Ram doesnt usually go bad.

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.

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.

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.

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. No need to clean the dust out first.

 

[paulmd]

Yes, that can produce the symptoms he is seeing.


Doesnt produce the symptoms he is seeing.


Unlikely to have just started to produce those symptoms.

I must disagree. But in any case, it needs to be tested.

Doesnt produce that reboot effect.


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.

Nope, that wont produce the reboot effect either.


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.

Not when the actual fault is elsewhere.


No they dont with symptoms like those seen.


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.

Nope, particularly when its quite likely that the motherboard
is bad and that the owner will choose to buy a new system.


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.

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.

Ram doesnt usually go bad.

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

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.


Stupidly inefficient way to diagnose a fault like that one.
Thorough.

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.


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.

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 )

 

[Rod Speed]

(e-mail address removed) wrote

Rod Speed wrote

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.

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.

and, they ARE problems.

You aint established that that system actually has any other problem.

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.

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.

Sure they can.
Nope.

With *any* program, windows, linux, dos or otherwise.

Wrong with stuff that makes few demands of 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.

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.

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.

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

Pigs arse it is.

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.

He didn't say so, therefore we can't assume.

Corse you can if you actually have a clue about efficient debugging.

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.

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.

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.

Its usually pretty obvious what can be a bios problem.

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.

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.

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.

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.

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

And then try swapping the power supply next.

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.

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.

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.

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.

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.

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.

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.

 

[xModem]

Ram doesnt usually go bad.

That's probably the dumbest bloody thing you've uttered yet. But the night is
still young...

 

[paulmd]

(e-mail address removed) wrote


Your problem.


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.

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.

You aint established that that system actually has any other problem.

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

Fraid so.


I KNOW that a bad cable and incorrect jumpering
cant produce that reboot effect the OP is seeing.


Mindless waffle with that particular symptom.


STILL doesnt produce that REBOOT EFFECT, and
that wont produce a fault that shows up later either.



Not even worth considering UNTIL he
has decided to replace the motherboard.


Wont happen if bad caps can be seen on the original motherboard.


I didnt do that, I JUST SAID THAT THEY WONT
PRODUCE THE SYMPTOMS HE IS SEEING.



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 there is JUST a bad cable, any decent diag wont just lock up.

Assumptions again. Bad form.

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.

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.



Pigs arse it is.

I've seen lots.

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.



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.

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.



Which is why anyone with a clue sees if the fault
remains with an absolute bare minimum of hardware.


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.

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.



Your neurotic hangups are your problem.


Dont need to do that BEFORE FLASHING THE BIOS.


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.

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.

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.

Waste of time with the symptoms seen.


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.

Not necessarily, most obviously when they arent necessary.

A detemination to make later.

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.

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.


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.

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.

Irrelevant to efficient fault finding.

My computers STAY fixed, do yours?

 

[Rod Speed]

(e-mail address removed) wrote

Rod Speed wrote

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.

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.

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.

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.

Assumptions again.

No assumption what so ever. It doesnt happen.

Bad form.

Pathetic excuse for mindless bullshit.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

A detemination to make later.

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

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.

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.

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.

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.

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.

 

[zzzzara]

Thanks for the advice. Have gone through all the suggestions:

1. RAM checks out okay

2. Very little dust, no visibly damaged components

3. there are no jumpers - it's a SATA drive

4. SMART utilities fail to get SMART info from the drive

5. Seagate and Maxtor's diagnostic utilities hang when I try to scan
the drive

6. switched cables - didn't make a difference; neither did moving cable
from one channel on the SATA controller to another

7. I have the latest BIOS upgrade

8. I moved the drive from the onboard VIA SATA controller to the
onboard Promise SATA controller. Unsurprisingly, it wouldn't boot (no
drivers installed) so I booted from my spare PATA drive and ran chkdsk
on the SATA drive. It worked - finding and fixing a few lost clusters.
I wondered if this had fixed the problem, and so moved the drive back
to the VIA controller -the problems were still there.

So, am I right to assume it looks like a really strange hardware
problem with the VIA controller? Do you think it's safe to just forget
about the VIA controller and just move the drive over to the Promise
controller for good?

Would really appreciate your help on this

 

[NZLamb]

Your diagnosis shows it is very likely the VIA controller is to blame here,
and if moving to the Promise one fixes this then that could be considered a
quick fix.

Unfortunately it doesn't fix the original problem of a possible faulty
motherboard chipset, so if it is still under warranty you should ideally
return the board for replacement. If not then there is a possibility you
could encounter further problems down the track with that board.

Jeremy

 

[Rod Speed]

Thanks for the advice. Have gone through all the suggestions:

1. RAM checks out okay

2. Very little dust, no visibly damaged components

3. there are no jumpers - it's a SATA drive

4. SMART utilities fail to get SMART info from the drive

smartctl from a knoppix CD should be able to see it.

Unlikely that the drive is a problem tho since you
got the same problem with two different drives.

5. Seagate and Maxtor's diagnostic utilities
hang when I try to scan the drive

6. switched cables - didn't make a difference; neither did moving
cable from one channel on the SATA controller to another

7. I have the latest BIOS upgrade

8. I moved the drive from the onboard VIA SATA controller to the
onboard Promise SATA controller. Unsurprisingly, it wouldn't boot
(no drivers installed) so I booted from my spare PATA drive and
ran chkdsk on the SATA drive. It worked - finding and fixing a few
lost clusters. I wondered if this had fixed the problem, and so moved
the drive back to the VIA controller -the problems were still there.

So, am I right to assume it looks like a really
strange hardware problem with the VIA controller?

Did you check the motherboard for bad caps ?

Does it still spontaneously reboot ? How often ?

What's in the event log ?

Did it ever work properly ?

Do you think it's safe to just forget about the VIA controller and
just move the drive over to the Promise controller for good?

Not if there are bad caps on the motherboard. Thats likely to bite in future.

 

[zzzzara]

smartctl from a knoppix CD should be able to see it.

Unlikely that the drive is a problem tho since you
got the same problem with two different drives.

Sorry if I wasn't clear, the problem has only been on my SATA drive. I
wanted to rule out software issues so booted from the PATA drive and
then ran a chkdsk on the SATA drive. The PATA drive has always worked
fine.

Did you check the motherboard for bad caps ?

None I can see.

Does it still spontaneously reboot ? How often ?

What's in the event log ?

haven't had a chance to boot up from the Promise controller, but shall
do so this evening.

I'd had random reboots for a couple of weeks. Discovered yesterday I
could trigger them consistently if I did something that scanned every
file on the disk (virus scan, backup). When I realised my daily backups
were no longer working I ran the chkdsk and discovered there was
something odd going on.

Did it ever work properly ?

worked fine for the last 18 months, although I don't think I ever ran a
chkdsk. I suppose it's possible there's something odd about one sector
on the hard disk which throws the VIA controller but not the Promise
controller, and data has only gotten into this sector in the last few
weeks.

thanks again for your time.

 

[Rod Speed]

Sorry if I wasn't clear, the problem has only been on my SATA drive. I
wanted to rule out software issues so booted from the PATA drive and
then ran a chkdsk on the SATA drive. The PATA drive has always worked
fine.


None I can see.


haven't had a chance to boot up from the Promise controller, but shall
do so this evening.

I'd had random reboots for a couple of weeks. Discovered yesterday I
could trigger them consistently if I did something that scanned every
file on the disk (virus scan, backup). When I realised my daily
backups were no longer working I ran the chkdsk and discovered there
was something odd going on.


worked fine for the last 18 months, although I don't think I ever ran
a chkdsk. I suppose it's possible there's something odd about one
sector on the hard disk which throws the VIA controller but not the
Promise controller,

Unlikely. Its more likely that the via controller doesnt
like the sata drive and the promise is happy with it.

and data has only gotten into this sector in the last few weeks.

That shouldnt produce a spontaneous reboot or lockup chkdsk or the diag.

The via controller not liking the sata drive could well produce
those effects but its hard to see that that would have worked
fine for 18 months and now is producing those effects.

Have you got the sata drive jumpered for sata1 ?
That motherboard needs that.

 

[paulmd]

thanks again for your time.

Given the additional info you provided, I believe this disk is
physically bad.


It's also still possible that bad caps are responsible. They don't
always fail visibly.

It's still possible that your SATA controller wigged out. To prove
this, however, you'll have to see what it does in another machine.

But, at this point, the odds are *strongly* in favor of it being a bad
drive.

 

[Rod Speed]

(e-mail address removed) wrote

(e-mail address removed) wrote

Given the additional info you provided,
I believe this disk is physically bad.

That shouldnt produce spontaneous reboots.

Its more likely that its actually the A8N not liking SATA2 drives.
That would explain why it works fine on the Promise card.

It's also still possible that bad caps are
responsible. They don't always fail visibly.

It's still possible that your SATA controller wigged out. To prove
this, however, you'll have to see what it does in another machine.

But, at this point, the odds are *strongly* in favor of it being a bad drive.

Wont be that, it works fine on the Promise card.

 

[dan.neidle]

(e-mail address removed) wrote


That shouldnt produce spontaneous reboots.

Its more likely that its actually the A8N not liking SATA2 drives.
That would explain why it works fine on the Promise card.




Wont be that, it works fine on the Promise card.

Now the SATA drive's connected to the (onboard) Promise controller it's
working fine, and has passed every diagnostic I've thrown at it. More
importantly, the backups/virus scans which previously triggered a reset
now work without a problem.

Thank you all for your help!

 

[Rod Speed]

Now the SATA drive's connected to the (onboard) Promise controller
it's working fine, and has passed every diagnostic I've thrown at it.
More importantly, the backups/virus scans which previously triggered
a reset now work without a problem.

Thank you all for your help!

Thanks for the washup.