> On Wed, 28 Jul 1999, David Hamm wrote:
>
> > Stranger yet. I've found that I can turn on level 2 cache and set the access
> > speed of the ram to 7ns ( which is even faster than before ) and the problem
> > goes away. If I leave the speed set to 7ns will I have problems later?
>
> Hmmm. What I'd recommend is running a script overnight; compile the
> kernel over and over and over again. This seems to be the single best way
> to find hardware problems in Linux. If you can compile, say, 50 or 60
> kernels without a seg fault or other error, then you're probably safe
> leaving it at that speed.
Not really. If you keep doing the same thing you probably won't hit the problem,
unless you hit it on the first pass. They are usually _very_ subtle, and if you
hit a problem you need to keep repeating that _exact_ same thing to investigate
that problem. The activity which triggers the problem usually has some specific
quality, like a particular address change pattern. You probably won't get that to
happen if you just keep repeating similar operations. The cause of these problems
is usually flaky chip sets (like several from Intel have been flaky) or poor board
layout. That sounds like the chip set or board is bad news, and should be avoided.
However, on some boards where I have had this type of problem trying several makes
of RAM until we found a "compatible" one has resulted in a machine which never
crashed again. Another case of plug and pray.
Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/