[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