Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

OT: CPU will not boot



jbk wrote:
> The system is an MSI socket 462 MB w/ onboard 8x AGP video out, AMD 
> 1.4Ghz Atholon chip, 512 Mb DDR PC333 Mem, USB 2.0.
> 
> The system powers up, cpu fan and power supply fan run.
>
> The things I have done to diagnose the problem are; remove graphics card 
> and use the onboard video, change memory slot, disconnect front side USB 
> port, remove and reconnect IDE cable. All of these resulted in no net 
> change in response, a blank video screen.

Have you plugged in or verified that there is a working speaker attached 
to the motherboard? When you have a system that won't POST, being able 
to listen to the beep codes is critical.

If the system isn't old enough to be considered disposable, you might 
want to buy a POST card that will display the error code on an LED 
display. (These used to cost a few hundred, but now can be found for 
about $30.) Much nicer and more specific than beep codes, providing you 
have the manufacturer's table of codes. (Though they're semi-standard.)


> ...I would think that a bad HDD would not effect the video, I should 
> still be able to access the Bios which I cannot. 

Correct. With the exception of some freak occurrence where a failing 
drive or controller is interfering with the main system bus. Even then, 
buffering at various points makes that highly improbable. In any case, 
it is easy enough to test by removing the drive cables and/or controller 
(if it is a plug in card).


> What would kill the video?

It's not so much the video as the CPU. It sounds like the CPU is failing 
to work at all, though once you've checked for beep codes, you'll know 
more. If there are none, you've got a dead CPU or critical motherboard 
component.


> Two days ago it took five tries at pushing the start button to get it
> to boot... The next time or next day, nothing I could do to get post
> up...

This is not an unusual failure mode for machines that are left running 
constantly for years, and then shut down briefly for maintenance. Once 
the system cools off, bad connections and other more significant 
thermally triggered failures can occur. Years ago, this often happened 
with hard drives. The old "stiction" problem with the bearings.


> I was not there when initial event happened or I would 
> have checked the event log...

It probably would have shown nothing.


> I went out and bought a second power supply and installed it, there
> was no improvement.

A power supply tester (with dummy load) might have been a better investment.


> ...[removed] graphics card and use the onboard video

This typically requires changing a BIOS setting, so if you haven't been 
able to access the BIOS, that still might be a problem. Following the 
procedure to clear the CMOS memory is one way you might force it back to 
the default of using the onboard video.


> I will see if I can verify the memory on my other system and the AGP 
> card. 

Both worthwhile steps.


> What else can I do?

Remove everything from the board except one memory module that you've 
verified elsewhere and a speaker and see if you can get it to POST. If 
not, you've got a dead motherboard or CPU. Chances are it won't be worth 
your while to pin down specifically which of those two, once you've 
gotten to that point.

  -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org