Systems of that vintage often suffer from failed motherboards - and you can often inspect them visually for it. Have a look at the capacitors, particularly on the "upper left" side of the board, between the CPU socket and the PS/2 port. These are used for power regulation, and during the period that most of the late Pentium 2's, early Pentium 3's, similar era AMD's, etc were produced there was a bad batch of electrolyte product that went through Taiwan. Many of the manufacturers incorporated capacitors made with that electrolytic fluid, and over the past year or so failure rates of that era of motherboard have been ridiculously high. The obvious signs will be "bubbled" capacitors -- if the top of the cap is not very close to level, particularly if it bulges in the center or along the top seams, it's very likely going bad. You may also notice an actual leak at the bottom of the capacitor that is visible on the board as corroded fluid.

The bad news is, of course, those motherboards can be hard to find locally any more. Intrex stopped carrying Socket 370 motherboards around a year ago, and I don't know of anyone else locally that might have them. If they are for sale, expect high prices. Your best luck is probably Ebay.

The good news, is caps are the problem, all hope is not lost. I've had remarkable success with replacing capacitors on older motherboards, and turning them from unstable messes of uselessness to nice stable machines that are in current production use. If you need advice in replacing the caps or assistance, contact me off-list. You can purchase what ever replacement caps you'd need from Digikey (http://www.digikey.com). I also have a rather large stock of Caps if you just need a few I will part with them for what I paid for them from Digikey (plus shipping - I used to purchase them 100 at a time, bulk pricing is a good bit cheaper). Because they are only 2-pin devices, they are relatively easy to replace with an adequate soldering iron and a solder sucker. If you have the luxury of old dead hardware, practice on it first. :)

Best of luck with it,
Aaron S. Joyner


Mike Parkhurst wrote:


If this were my box I'd bring it down to minimal configuration (like someone else suggested), and then run memtest on one stick of memory at a time. If all the memory is bad, then the MB is probably the problem (unless of course all the memory really is bad).
I have run into cases where each part tests good, but when everything is put together it craps out. This may be due to the 185W power supply. I have also had systems of this vintage where any two sticks of memory work fine, but adding a third stick destabilizes the system even with a large power supply. I suspect the MB cannot provide enough power, but don't know for sure. Alternately, memory was expensive when this MB was designed. I have read MB manuals that said something to the effect of "This system was designed to work with 128M memory sticks, however they are not currently in production and therefor we could not test them with our product".


Mike

Brian A. Henning wrote:

Hi guys,
 This is more of a hardware issue, I believe, than software, but we are
trying to install FC1 so I think it counts, right? :-)  At any rate...

The patient is a friend's aging Celeron 433 from CompUSA. Un-branded
baby-ATX mobo, sporting a SiS 5595 southbridge chipset, onboard
audio/video/usb, socket 370. 256 MB RAM, split among one 128 and two 64 MB
sticks (PC100 SDRAM). Wimpy 185 max wattage PS, but there's only one
Seagate 4.something HD, one 48X Max CD-ROM, and floppy drive.


The problem is we have been wholly unsuccessful in installing jack squat on
this thing. Further maddening is the fact that the only reliable outcome is
that it WILL choke somewhere along the way. Where, and how, remains largely
random. I really believe it is a faulty mobo or CPU to blame, but I wanted
to present the symptoms for someone else who may be able to give a more
authoritative "I agree."


As I mentioned, in most instances, the installation process simply freezes
at a random point. However, some minor patterns did emerge.


If booting from CD, the boot process was most likely to freeze at one of the
following two points:
Immediately after
RAMDISK: Compressed image found at block 0
or at
running /sbin/loader...


Turning off the framebuffer (as /sbin/loader is the point at which that
appears to begin making a difference) actually proved to be
detrimental---with the nofb boot option, often the left third of the screen
would become filled with a column of garbage characters (in textmode---the
one time X successfully started, there were a couple columns of garbled and
reflected pixels [snowy images of other parts of the screen], and it froze,
so we stuck to textmode from then on).


Using the mediacheck option sometimes managed to push the process through to
the media verification, during which (somewhere in the 20% range) the
computer spontaneously rebooted itself.


Booting from floppy and attempting an FTP install most commonly froze after
Transferring Fedora/base/netstg2.img, before anaconda was launched. A few
times, Anaconda was launched and got as far as detecting the video, monitor,
and mouse before freezing. Once, ONCE, the process got as far as completing
Disk Druid. Once. Out of what felt like hundreds of attempts. Only twice
did the process get even as far as selecting Desktop, Laptop, Server, or
Custom installation variety.


We've played with RAM timing (the primitive Award bios, the most recent
available for that hardware being two years old, offered little Wait State
adjustment [0WS or 1WS]---that was one suggestion we came across...also
futzed with SDRAM Input and Output signal timing), IDE transfer modes, and
other sundry BIOS options, generally to no perceivable avail.


Other common exits were the infuriatingly vague "Installer terminated
abnormally," or a Kernel Panic claiming inability to mount root file system
at either 09:01 or 48:03 (I believe).


cpio: bad magic
was also a common apparently nonfatal error, which seemed to be loosely tied
to enabling 32-bit IDE transfers.


We reseated everything multiple times. I noted that the first two DIMM
slots seemed rather loose; I don't know if they were electrically loose, but
they definitely felt as though they did not have a strong mechanical grip on
the DIMMs. I borrowed some RAM from a friend to swap out. memtest86
crashed at about 60%. I don't think the ram sticks themselves are to blame.


We tried numerous IDE cable swaps. Unhooking the CD-ROM. Unhooking the HD,
just to see if it would boot all the way (it still randomly froze).


The absolutely most maddening, frustrating aspect is that insanity reigned
supreme---meaning that exactly the same input often yielded wildly differing
results.


Other distros that failed to boot successfully included SuSE Live Eval 9.0,
Knoppix 3.3, Red Hat Linux 9. WinXP also failed to make it all the way
through the boot process.


So the total of all that makes me think it's hardware. Anyone able to
evaluate these symptoms and say "yeah, you're probably right?" If there's
something we're missing, we'd love to know about it. My friend is new to
the linux world and is eager to plunge in and learn his way around FC.


If anyone has an old mobo with the same baby-ATX form factor sporting Socket
370, or a Socket 370 processor around 433MHz they'd be willing to lend or
part with so we can try other hw, let me know. I'd definitely appreciate
it.


Thanks a lot for wading through all this and offering any insight.

Cheers,
~Brian





-- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ TriLUG PGP Keyring : http://trilug.org/~chrish/trilug.asc

Reply via email to