[TriLUG] quasi-OT: Hardware Issue confirmation?

Morris Walton mwalton at nc.rr.com
Sat Mar 27 08:39:19 EST 2004


Sounds like hardware to me too.  You could try swapping the memory
first..... 

Morris


On Sat, 2004-03-27 at 03:19, 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





More information about the TriLUG mailing list