From: hlu@luke.eecs.wsu.edu (HJ Lu)
Subject: Re: Debugging possible hardware problems
Article-I.D.: serval.1993Apr20.151405.12480
Organization: Washington State University!
Lines: 54

In article <1r0rslINNnv2@senator-bedfellow.MIT.EDU> jfc@athena.mit.edu (John F Carr) writes:
>
>I'm running Linux on an 80486 EISA system, and I'm having what I think are
>hardware problems.  It could be software, but I don't see why I'd be the
>only one having trouble.  I'd like some advice on how best to debug this.
>
>The symptom: when I try to build gcc, I get unpredictable and unrepeatable
>results.  Sometimes a .o file is not in valid a.out format.  Recompiling the
>file gives me a valid binary.  Sometimes the compiler aborts or dumps core,
>but works fine when run again with the same input.  Compiling the same
>source files with the same arguments gives slight differences in a few
>object files.  (Note that Linux, unlike many other systems, does not put
>timestamps in object files so compiling twice should give bit-identical
>results.)
>
>I also have occasional filesystem corruption on my SCSI drive, but that
>could be caused by using development software.  It could also be related to
>my problems compiling.  The compile problems are not caused by disk
>problems: I get the same results whether I do my work on an IDE or SCSI
>disk.
>
>I've set the memory speed and cache write speed to the recommended values.

Recommended for what, DOS? That is a junk.

>
>I suspect the external cache, but I have no real evidence for this.
>
>The motherboard is a NICE Super-EISA with 256 KB write-back cache and a DX/2
>66 Mhz processor.
>
>What I'm looking for:
>
>	. A system test program to run under DOS or Linux

	Linux + gcc. Fire up gcc to compile libc and kernel at the
	same time running X11R5.

>
>	. Suggestions about the cause of the problem

	Bad memory, bad motherboard, bad cache.

>
>	. Suggestions about how to debug the problem
>

	change wait state of RAM.
	turn off turbo.
	change bus speed
	swap RAM.


H.J.
