Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 Feb 2000 13:19:32 -0700 (MST)
From:      Bruce Gingery <bgingery@gtcs.com>
To:        "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Cc:        freebsd-doc@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG
Subject:   Re: Recommended addition to FAQ (Troubleshooting) 
Message-ID:  <200002182019.NAA29729@ home.gtcs.com>
In-Reply-To: <79456.950901038@zippy.cdrom.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 18 Feb 2000, Jordan K. Hubbard <jkh@zippy.cdrom.com> 
issued forth a missive of approximately 3647 bytes,
entitled "Re: Recommended addition to FAQ (Troubleshooting) ",
the text of which in full or in part is quoted here:

-} The situation here, I hate to say, is that you were simply very lucky
-} in having a software memory tester show you anything at all.
-} 
-} If your experience had been more typical, you would have run memtest86
-} and it would have declared your memory to be free of errors.  Then
-} you'd have gone right on having problems and losing more hair until
-} you finally just came back to the memory and swapped it out on
-} suspicion.  Bingo, the problems are suddenly fixed and you're dragging
-} memtest86 to KDE's trashcan with a resolve to never trust it again.

    Hmmm, maybe TkDesk's trashcan  :)   I use Fvwm2.

-} The reason why software memory testers are so generally ineffectual is
-} that there's a whole bunch of things getting in their way.  Leaving
-} aside for the moment the nasty problem of having your memory checker
-} loaded into the bad memory in question, the cache also seriously gets
-} in your way (and I'll bet you never even thought to turn both L1 and
-} L2 caches off, did you? :-)
[munch]

   As I understand it, I was getting a report of page faults
   in kernel on that machine.  I KNEW something was wrong, and was
   quite sure it wasn't the build of FreeBSD :)  With the machine nearly
   a thousand miles from me, it was difficult to tell for sure that
   I got a good sense of _everything_ that was going on.

   This is the second time I've had bad RAM since starting to use
   FreeBSD (and once, previously, while using NeXTstep) and had
   difficulty in pinning it down.  Actually, I tried another (at the
   time it was DOS based) memory checker the previous occasion which
   revealed NOTHING, and that's why I was a little quicker to jump to
   an assumption that it probably WAS bad RAM this time, rather than 
   bad diskettes etc.

   In simple point of fact, you're right.  I did NOT manually disable
   cache in the BIOS, because it never got that far.  The memtest86 
   runs a series of tests with and without cache...  That machine has
   one bank of 64M and all internal cache, so chip switching wasn't
   an easy solution, ESPECIALLY at this distance.

[quote memtest86 docs]
Test  0 [Address test, walking ones, no cache] 
Test  1 [Moving Inv, ones&zeros, cached] 
Test  2 [Modulo 20, ones&zeros, cached] 
Test  3 [Address test, own address, no cache] 
Test  4 [Moving inv, 8 bit pat, cached] 
Test  5 [Moving inv, 32 bit pat, cached] 
Test  6 [Moving inv, ones&zeros, no cache] 
Test  7 [Modulo 20+, ones&zeros, cached] 
Test  8 [Moving inv, 8 bit pat, no cache] 
Test  9 [Modulo 20, 8 bit, cached] 
Test 10 [Moving inv, 32 bit pat, no cache] 

(AND) ...test memory using longer refresh rates. This makes is possible
to detect marginal errors that otherwise would go undetected with the 
normal refresh rate.  Three refresh rates are available, the normal 
rate of 15ms, an extended refresh rate of 150ms and an extra long rate 
of 500ms. The default refresh rate is used for test 0 and tests 1 - 7 
use an extended rate of 150ms. The extended tests (8 - 10) use the extra 
long refresh rate of 500ms. The refresh rate may be overridden at any 
time via online configuration commands. 
[end quote]

    While I FULLY understand your hesitancy, and yes, even if
    RAM passes all of these tests that is not a sure indication
    that the RAM is good,  but it's a sure problem when it FAILS.
    reproducably.  With my daughter's machine, the errors started
    showing on test 4, and from what I can tell, about 1/3 of the
    way up the 64M.  A failure at a different point, of course
    might have given different symptoms, and a failure of a different
    type might indeed NOT have been detected by memtest86.

    Also, not all of us are as happy with fingers inside the case as
    on the keys or pointer, however long we've been at it.  :)

    The reason I was suggesting the second program be run at
    boot (before multiuser startup) was not to give a false
    sense of security, but rather one more possible safety
    margin.

    I can completely understand your hesitance, and the reasons
    for it.  I do wonder though, if there isn't some way to 
    make it clear to people that this is a precaution, that
    may be "better than nothing", even if it is not a 100%
    effective safeguard against hardware malfunctions.  It's
    EXTREMELY difficult to "bootstrap" a hardware test, by using
    the same hardware that is questionable.  I don't really think
    it could be 100% effective.

    OTOH, I really DO understand your position on this.  I just argued
    the opposite direction about the Stacheldraht/TFN2K checker for
    Solaris and Linux which has been put up on the FBI's NIPC site, and
    with much of the same reasoning you display about this RAM test
    software.

    That "signature checker" which is documented as tested on 3
    versions of Solaris, and 2 RedHat distributions, but NOT able to
    handle a.out nor COFF binaries, is (perhaps) worse than nothing at
    all, because of the false sense of security it might convey.  Of
    course, one additional thing against it is that it's a binary-only
    distribution that they say _must_be_run_as_root?! (apparently 
    it does direct memory access to loaded code in addition to
    scanning stored binaries for a recognizable compiled signature?)  

    Am I the only one seeing something windowsey about that?  Who gets
    to make the recurring profits this time for band-aid solutions to
    a spurting artery.
    
	http://www.fbi.gov/nipc/trinoo.htm

    So I'll leave it up to you.  There should be info at least in
    a FAQ somewhere that indicates that bad RAM is not something
    that can be ruled out until tested adequately, and perhaps a 
    checklist of symptoms that (virtually) ALWAYS indicate bad RAM,
    or at least should make it suspect.

	Bruce Gingery	<bgingery@gtcs.com>





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200002182019.NAA29729>