On Wednesday 12 October 2005 22:01, Anthony Anson wrote:
Before you pass on to the next item, the Linux issue appears shortly...
I've just put a box together (AMD 900, nine hundred and mumble mumble MB RAM).
IDE Channel 1: HD0 (master) and CD/DVD-RW (slave), cable detect IDE Channel 2: HD1 and Zip100 - both slave - not cable-detect. UW SCSI card and 2 � UW SCSI HDs ATI Rage 128 AGP card Internal hardware modem, PCI (can't unforget which one)
<...snip...>
I'd also like the computer to work, as the one I'm on (PIII-450) I've built for a friend whose PI-90 is rather sick.
Well, there are so many things to try. Can't distance-analyse your problem from here. Can type a lengthy and technically naive stream-of-consciousness on what I'd do though, saving me from doing some work I should be doing. Maybe something will spark an idea at your end, that's how it works with me :)
Personally, I'd be thinking stuff like 1. mobo/gobo(gpu) problem (acpi allergy, pci problems/conflicts etc) 2. Same thing really, but incorrect BIOS Settings (Especially stuff left from an old system or loaded from a "safe defaults" bios profile - like wrong FSB, ram timings, AGP driving strength, PCI Latency or just random stuff that wants toggling - iirc don't rages need assign irq to vga enabled in the bios or by a switch on the gobo?) 3. Faulty RAM - the Force suggests this, but I've not really enough info, heh. 4. Insufficient, excessive or failing power.
Firstly, it's easy to remove your hard drives and superfluous devices, so I'd do that anyway (I wouldn't be letting anything access your hard drives until you've OK'd the memory, because faulty ram can severely bork file systems, I've cleverly discovered :P ).
(aside: If there are enough PCI slots, have nothing in the 1st PCI slot - it can conflict with some mobos/gobos. Also some cards that conflict horribly with an agp gobo can be sorted out by adjusting the pci latency on a trial-and-error basis.)
(another aside - windows 2000 and modern linux-based OSes do things win98 doesn't - especially as regards power management and device detection and IRQs)
Anyway, higher level diagnosis could be useless whilst you might still have faulty ram, which can mimic the symptoms of, or cause various other hardware failures.
Now I'd physically check the card (obvious stuff, and definitely check the Heatsink/Fan are functional/not coming away from the GPU, and test it in another machine) and reseat it, and ONE stick of ram - blowing all the relevant slots out for dust (always, heh).
Then I'd place a memtestx86 boot disc in the drive, and since dodgy BIOS settings can literally fry a graphics card, I'd boot the machine into BIOS setup. After giving it the once or twice over to make sure there's nothing dangerous/obvious, I'd boot into memtestx86 and test the stick of RAM exhaustively.
I'd then rinse and repeat for additional sticks (Legal disclaimer: do NOT rinse your RAM), testing each on its own.
Now, having checked the card in another machine and found it to be working, I'd run the whole system through the sort of binary test described elsewhere in this thread.
Note, if the problem hadn't been sorted out I'd tend to use a read-only filesystem like knoppix's during the process of deduction, for the pure and simple reason that OSes which may or may not suddenly die without unmounting are likely to taint the process, and the disks' data.
HTHISW,
Ten