Quoting Cam Ellison ([email protected]): > On another list that I frequent, the two responses thus far both > suggested replacing or swapping out the PS. I have to admit the idea > has merit, though it's an Antec Signature 650, came new with the rest of > the system, and over $200 here including the taxes. I'm a little leery > of ending up with a good, but effectively useless, PS. Which leads to > another question: how do you test a PS? Is it possible?
I'm sure it's possible (at least in theory), but I never have tried. I've always just tried to keep around at least one of each major type with a piece of masking tape on it labelled 'known good as of [date]', and swap those into systems where I suspect the PSU. If the PSU is generally functional, then in my experience the usual question is whether it is too weak for the current draw asked of it. (In a perfect world, you would be able to believe manufacturer ratings, but of course they lie and exaggerate, and also doubtless some PSUs achieve their claimed ratings better loaded with some impedance types than others.) Antec PSUs are on the short list of ones I have faith in, generally. I have a confession to make: I really didn't pay much attention to this thread until I saw Brian mention CTCS (Cerberus), with which I have a great deal of experience. I've just now re-read your original posting to get the context for all this. That having been done, I think the suggestion of a (say, overnight) Cerberus run has a lot to recommend it. Cerberus puts a system under very, very serious load, which is the rationale for its use to stress-test newly constructed systems on the VA Linux Systems production line: It exposes most hardware flaws through thrashing the hell out of pretty nearly every hardware subsystem in the host. Your description (halted suddenly, no output, coldboot required) doesn't sound a-priori like a RAM problem. It's conceivable that it's a software problem, but my instinct says hardware is more likely. That instinct says it's likely to be something with either the motherboard + CPU or with the PSU. One avenue towards diagnosis (generally speaking and probably _not_ useful for your situation; this is just for general knowledge of troubleshooting) is to simplify the hardware situation temporarily for diagnostic purposes, to attempt to isolate the problem. That is, open up your system and look at what's plugged into what. Do you have expansion cards that can be disconnected and the system is still able to produce video? Remove them. A miniPCI-format wireless card? Unplug it. Non-boot hard drives? Unplug and detach them. Optical drives? Unplug and detach them. Get as close as you can to just motherboard + PSU and still have the system be functional enough to run and expose the syndrome if it's still present. That method is useful primarily for symptoms that express strongly and constantly, like 'System doesn't even beep or produce video'. In those cases, you detach every non-essential subsystem and see if the remaining hardware then beeps and does video. If it does, then the root cause lies in one of the subsystems you detached -or- in the 100%-wired-up system trying to draw too much current from a borderline PSU. If if doesn't, then the problem may be in the system core (motherboard, PSU, CPU, RAM). The latter case is of course tough to narrow down. If you have multiple sticks of RAM, and the motherboard northbridge can function with fewer than all of them, try with half the RAM, then with the other half, seeing if bootup beep + video reappears and correlates with one bank of RAM but not the other. Getting back to steps more likely relevant to _your_ problem, the other general class of diagnostic techniques involve swapping in known-good components, and seeing if the problem suddenly vanishes with one such swap-in. The pain-in-the-ass requisite is, of course, having a bunch of known-good parts sitting around for this purpose, which one only rarely has. Sorry, I don't know any easy way around that. -- Rick Moen "Told my friend she shouldn't smoke weed while she's [email protected] pregnant because her baby's never going to want to McQ! (4x80) come out." -- Kelly Oxford _______________________________________________ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
