Kinda off-topic.

On Mon, Aug 09, 2004 at 01:43:34PM -0700, Zach wrote:
> I see. Thanks for the elucidation. Do you have any options
> for determining whether a mother board has gone bad or
> whether it is certain card(s) or both? 

Yes.  Just like in a bicycle or car, substitute components until the
fault is found.  Uses Scientific Method.
http://en.wikipedia.org/wiki/Scientific_method

I rant more on this below.

> On my first computer about 12 months after I had it one day I powered
> it on but no boot noises or anything showed up on the monitor. So I
> took it to a shop and he said the mother board apparently short
> circuited and took out the RAM/video card/sound card along with it! 

I cannot vouch for the accuracy of this diagnosis, because I'm not in
front of the equipment concerned.  I can say that computer shops have a
vested interest in finding severe faults.  Get a second opinion; even
pay for a second opinion, in labor cost with a contract term that says
they will *NOT* get the business to fix it.  Tell them *why* you are
asking for that, but do *NOT* tell them the shop you used before.

I've been the second opinion consultant for about five dead systems out
here in the outback.  I haven't charged for this service (conflict of
interest with HP), but I have learned from it.

The farmers out here are about an hour or two's drive to the nearest
computer shop.  In one case, a "won't start up" 64Mb computer was taken
in on the morning and left at the shop for analysis and quotation.  This
was prepaid at $AUD 70.

When the owner returned around lunch time, the shop said "new
motherboard required, $AUD 800".  They'd even taken it apart to
determine this, and it was in pieces on the bench.  They were ready to
start.

The owner refused to believe it, and asked for the system to be
reassembled so they could get a second opinion.  The shop complied.
The owner then drove home.  (Remember, in the outback, it could be weeks
before they can get to town again).

When I got to analyse the system, with the owner present, I found the
following;

- mismatched RAM, some 4Mb SIMMs, one was physically damaged (missing
  pull-up resistor), definitely did not add up to anything like 64Mb,

- drive connectors not properly inserted, obviously a rush job
  reassembling,

- lithium clock battery showed 1.1V instead of 3.6V.

So I pulled out the bad RAM, changed the clock battery, fixed the drive
connectors, and the system worked fine.  I concluded that the original
fault was a flat battery, and that the shop technicians had not figured
this out in time.

Owner took it back to the shop on the next trip and demanded their money
and RAM back.  Shop apologised and gave them the RAM; which they had
found left over on their bench.  (The shop has since given *me*
excellent service, by the way, so I feel it was an isolated incident).

How you can learn to do the same?  I'm not really sure what to
recommend.  It's systematic diagnosis, based on understanding what each
component does and what it's limits are.  In my software support job at
HP, I have to use this all the time, but ask me to point a finger at
where I learned it, or how to learn it yourself, and you've got me
stumped.  It's too entrenched.

http://en.wikipedia.org/wiki/Engineering might help.  The systematic
diagnosis is a form of reverse engineering; we use engineering
principles to determine how a system *should* work, and then build up a
mental model, then test the model scientifically against the reality of
the failed system.  If necessary, we construct a description of the
problem and the tests that were carried out, just so we can be
methodical about how to solve the fault.

In supporting something that another part of the same organisation
produced, the situation can be easier ... because we have access to test
plans and procedures designed by the engineering team.  That's why
supporting Linux is so much easier ... we all have the source.

Never too old to preach.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/

_______________________________________________
vanilla-devel mailing list
vanilla-devel at us.netrek.org
https://mailman.real-time.com/mailman/listinfo/vanilla-devel