[TriLUG] quasi-OT: Hardware Issue confirmation?

[Mike Parkhurst]

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