From owner-freebsd-hackers Sat Apr 5 13:52:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA29301 for hackers-outgoing; Sat, 5 Apr 1997 13:52:05 -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 NAA29296 for ; Sat, 5 Apr 1997 13:52:02 -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 QAA20583; Sat, 5 Apr 1997 16:55:49 -0500 (EST) Message-Id: <3.0.32.19970405164743.00ac0524@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sat, 05 Apr 1997 16:47:46 -0500 To: Terry Lambert From: dennis 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.. I think you missed the "2 different machines" part.... > >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). > > > Regards, > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. > >