From owner-freebsd-questions  Tue Jun 18 07:53:14 1996
Return-Path: owner-questions
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id HAA01155
          for questions-outgoing; Tue, 18 Jun 1996 07:53:14 -0700 (PDT)
Received: from dtr.com ([205.139.102.204])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA01029;
          Tue, 18 Jun 1996 07:51:50 -0700 (PDT)
Received: from everest.dtr.com (everest.dtr.com [199.26.157.34]) by dtr.com (8.6.12/8.6.12) with ESMTP id HAA05538; Tue, 18 Jun 1996 07:47:09 -0700
Received: (from bmk@localhost) by everest.dtr.com (8.6.12/8.6.12) id HAA02502; Tue, 18 Jun 1996 07:46:49 -0700
Message-Id: <199606181446.HAA02502@everest.dtr.com>
Subject: Re: FreeBSD works with Cy486DLC processors?
To: alex@fa.tdktca.com (Alex Nash)
Date: Tue, 18 Jun 1996 07:46:49 -0700 (PDT)
Cc: bmk@fta.com, Eloy.Paris@ven.ra.rockwell.com, questions@FreeBSD.org,
        hardware@FreeBSD.org, hal@wwa.com
In-Reply-To: <31C69327.32639FD9@fa.tdktca.com> from "Alex Nash" at Jun 18, 96 06:29:43 am
From: "Brant M. Katkansky" <bmk@fta.com>
Reply-To: bmk@fta.com
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-questions@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk


> Brant M. Katkansky wrote:
> > 
> > > I installed FreeBSD 2.1.0-RELEASE a couple of weeks ago and since then I
> > > have been having programs exiting with signals 10 and 11, making my system
> > > too unstable to work as a dedicated e-mail server and as a PPP to Ethernet
> > > gateway.
> > 
> > [snip]
> > 
> > I had one given to me not too long ago.  Mine is plagued with various
> > sig 10 and 11's, same as yours.
> > 
> > Here's the interesting part - disabling the internal and external cache
> > makes the problem worse.

> This should be fairly easy to explain: You have bad SIMMs.  While your 
> program is running, erroneous results are returned from RAM and the 
> processor tries to execute them.  Your program subsequently seg faults 
> due to an invalid instruction.  If your cache works properly and your 
> SIMMs don't, the cache can mitigate these effects since RAM accesses are 
> less frequent (thus missing the odd inverted bit somewhere :) ).  Disable 
> the caches and now you will be much more likely to see a bad SIMM in action.

That hadn't occurred to me - I was operating under the assumption
that the board was garbage.  I'll swap out the RAM and see what
happens...