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