[gentoo-amd64] Re: Initial install issues

[Duncan]

Lance Jacobs <lance@×××××××.net> posted
Pine.LNX.4.64.0605311051370.17278@×××××××××××××××.net, excerpted below, on
 Wed, 31 May 2006 10:58:16 -0400:

> Just FYI, I have this fixed now, and you were right on the money.  I
> wouldn't have believed it if I hadn't seen it, but it was the RAM.  I
> replaced the OCZ memory with equivalent parts from Crucial, and the
> system is fine now.  It still seems strange that many things seemed to
> run fine with the old RAM, except for bunzip2 and md5sum, and now
> everything is good -- only some code is intolerant of bad bits?  It just
> seems wrong....  Anyway, the system is rock solid now.

It's all down to the application (as in what the software is does,
rather than as in the specific executable)... md5sum and bunzip2 just
happen to be in a class of application that happens to be more sensitive
to this sort of thing than others, since their application (or part of it)
is that they both verify integrity, and even a single bit-flip somewhere
will cause that verification to fail. Most applications aren't that
sensitive.  In a normal executable, a single random bit-flip won't make a
lot of difference.  If it's in the lower order bits of an image bitmap or
sound sample, you'll not notice it at all (see steganography), and
certainly the result can still be played or viewed without error.  If it's
in the wrong place in an executable, you'll get bad results, but likely
not bad enough to immediately crash, but rather, output that gets worse
and worse, executables that get less and less stable, over time.  If you
don't tend to run executables for days or weeks at a time, if you shut
down your computer when not in use, and you never use integrity
verification applications, such memory unreliability may go entirely
undetected and unsuspected.

You mention that you have the memory in something else now, for further
testing.  Note that depending on the exact nature of the problem, the
memory may come up clean on a different mobo.  Hardware tolerances and
resistance to data signal noise being what they are, it's entirely
possible the memory was just at one end of the spec and the board at the
other, in terms of tolerances that would work, and they were thus
incompatible with each other, while each remains within spec or only
slightly out of spec, and will work with 90% of what's out there -- they
just wouldn't work when that particular memory was in that particular
board.

Based on the experience I had (which I posted earlier), you may also find
that the memory is perfectly fine under most conditions, but is subject to
errors in certain corner conditions.  If you've ever seen the complete set
of non-auto memory parameters available in some BIOS setups, there's quite
a list of them, ten or so.  If one of the rare corner-case ones doesn't
meet the on-stick memory ratings by even a single clock, but that state
transfer doesn't happen very frequently and even when it does, all but one
of the chips on the stick is fine with it, and even then, that single
exception only happens in a certain temperature zone in the case of the
third memory access in a row of a specific pattern, it could be extremely
difficult to find or verify, yet cause annoying problems just often enough
to be a real frustration!

You did mention that the memory was under warrantee, however, and that
it's going back, regardless, and that's a wise decision.



-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@g.o mailing list