[TriLUG] quasi-OT: Hardware Issue confirmation?

[Aaron S. Joyner]

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
>>
>>  
>>
>