On 12/23/05, Daniel da Veiga <[EMAIL PROTECTED]> wrote: > 3) Check (not necessarily in this order): MOBO, Processor, memory, > video. (if you don't have the spares necessary, take it to someone you > trust and can test the hardware).
It sometimes isn't even necessary to swap out this hardware. You can usually go into the BIOS and adjust the memory timings and CPU speeds to identify the problem. For example, I just built an AMD x2 system. But I have had a lot of trouble getting the system stable. BIOS wouldn't even post with the first 2 sticks of RAM running at their rated timings of 2-3-2-6, but would post fine at 3-4-3-6. So I replaced those. Then I couldn't get a compile of ghostscript to complete without causing a kernel panic...so back into the BIOS I went. Eventually I reduced the CPU multiplier from x11 to x10 (2.2 to 2.0 Ghz), and everything compiled cleanly. So I exchanged that CPU, and emerge -e world worked at 2.2Ghz. Now I should say that the system was still unstable...getting a kernel panic every few hours. Actually, I can cause the kernel panic by saturating the SATA bandwidth (dd if=/dev/zero of=JUNKFILE bs=64k). So while the replacment hardware has helped, I am currently running it with the slow memory timings and the x10 multiplier. I haven't gotten back to testing the hardware again yet to figure out if the CPU or memory is still bad, or if the nvidia chipset in the shuttle XPC is crap, (which is what I truly suspect). > 5) Software is not a good way to test hardware (*IMHO*), the > exceptions are memtest and some benchmarks. IMO memtest is almost useless today. It can tell you if you have a bad memory cell, which is incredibly rare, but cannot identify the more common timing or chipset problems. "emerge -e world" seems to be the best way to identify faulty hardware! -Richard -- [email protected] mailing list
