From owner-freebsd-hackers  Sat Apr  5 13:51:01 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id NAA29215
          for hackers-outgoing; Sat, 5 Apr 1997 13:51:01 -0800 (PST)
Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA29210
          for <hackers@freebsd.org>; Sat, 5 Apr 1997 13:50:57 -0800 (PST)
Received: from dialup-usr11.etinc.com (dialup-usr11.etinc.com [204.141.95.132]) by etinc.com (8.8.3/8.6.9) with SMTP id QAA20568; Sat, 5 Apr 1997 16:54:16 -0500 (EST)
Message-Id: <3.0.32.19970405164610.00ac1574@etinc.com>
X-Sender: dennis@etinc.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Sat, 05 Apr 1997 16:46:15 -0500
To: Terry Lambert <terry@lambert.org>
From: dennis <dennis@etinc.com>
Subject: Re: 2.2.1R NFS and FTP load problem FOUND
Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, hackers@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

At 01:29 PM 4/5/97 -0700, Terry Lambert wrote:
>> >More likely, your RAM is flakey, and you are simply changing the
>> >usage pattern such that the flakey RAM is no longer critical path.
>> >
>> >Any chance of you playing a game of "shuffle the SIMMs" to verify
>> >this?
>> 
>> As I said, 2 different machines were involved, so the likelihood of
>> it being flakey ram is rather unlikely. Plus the same ram was used
>> when it works (just added another bank).....
>
>The same code was not necessarily loaded into the same spot.  If there
>was more RAM, the code exhibiting the problem could have been loaded
>into the additional RAM instead of the flakey RAM.  This would depend
>highly on the exact usage patter by processes invoked during install,
>including, but not limited to, their invocation order, etc..
>
>There is no evidence, short of a shuffle, that will guarantee you
>that the problem is resolved, not masked by the additional RAM.
>
>You will need to do a full shuffle so that an 8M situation without the
>possibly flakey RAM is also tested (and verified to fail).

Ok, but why can I load any OTHER version of Freebsd on these machines, and
what is
the chance of a random ram problem having the exact same failure on 2
different
machines? I dont buy it.....sounds like a "mine works so you're wrong"
answer to me.

db