[off topic] Re: Strange System Behavior

Stephane Belmon (sbelmon@cs.ucsd.edu)
Fri, 4 Dec 1998 00:21:59 -0800 (PST)

On Thu, 3 Dec 1998, Paolo Galtieri wrote:

> Motherboard: ASUS Dual Pentium II (350Mhz) w/ on board SCSI
> 1 4.3 GB disk
> 1 9 GB disk
> 1 5.1 IDE disk
> Matrox G200 video card
> Ensoniq AudioPCI sound card
> Eexpress pro 100 Ethernet card
> 1) When I build the kernel it takes about 10 - 20 tries to get it to
> build. This is due to the compiler terminating with sigsegv or
> other error. I'm using the gcc- compiler.

That's the most revealing thing I think, and the real question is: is it
random or not? If it is, welcome to PC hardware, which might be,
quality-wise, well, not as good as what you could be used to. My guess is
_really_ bad RAM, and not ECC nor parity.

Check out the FAQ:
and the SIG11 FAQ:
Read it and check your symptoms against it.

My 2 cents: when buying RAM, and ECC isn't an option (like almost always
:-/ ), I'll have the machine compile for days, logging any errors. If it's
bad, I'll return it. And I'll keep returning; the last time I bought some,
I had to return it twice. The first one was so bad that a kernel compile
would hardly ever finish, the bit flips would actually show up in the
buffer cache (I could _see_ a weird character in some source files), and
after one night of heavy load it trashed my ext2fs so bad, e2fsck showed
so many errors, I didn't take a chance and reformatted. When testing RAM,
only write mount partitions that you can afford to lose. I do the stress
load _before_ installing the new chips, and after, just to see the
difference. I'm not even sure perfect chips exist: the third set I got
still gives me an error every couple days or so --- under continuous
stress load (compile after compile).

For some reason, it seems to me that the chips that come with machines are
better than the ones you buy as parts. It might also be the stress they go
through when installed by someone who doesn't make a living of installing

Stephane Belmon <sbelmon@cse.ucsd.edu>
University of California, San Diego
Computer Science and Engineering Department

- 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/