l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
November 4: Social gathering
Next Installfest:
TBD
Latest News:
Oct. 24: LUGOD election season has begun!
Page last updated:
2010 Dec 08 15:52

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Problem with Gigabyte 890FX, Phenom II, and Kubuntu
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Problem with Gigabyte 890FX, Phenom II, and Kubuntu



Quoting Cam Ellison (cam@ellisonet.ca):

> 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 
rick@linuxmafia.com       pregnant because her baby's never going to want to 
McQ!  (4x80)              come out."                   -- Kelly Oxford
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.