From owner-freebsd-hardware  Tue Jun 18 04:26:48 1996
Return-Path: owner-hardware
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id EAA19865
          for hardware-outgoing; Tue, 18 Jun 1996 04:26:48 -0700 (PDT)
Received: from shogun.tdktca.com ([206.26.1.21])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA19860;
          Tue, 18 Jun 1996 04:26:46 -0700 (PDT)
Received: from shogun.tdktca.com (daemon@localhost) by shogun.tdktca.com (8.7.2/8.7.2) with ESMTP id GAA16318; Tue, 18 Jun 1996 06:28:10 -0500 (CDT)
Received: from orion.fa.tdktca.com ([163.49.131.130]) by shogun.tdktca.com (8.7.2/8.7.2) with SMTP id GAA16306; Tue, 18 Jun 1996 06:28:09 -0500 (CDT)
Received: from orion (alex@localhost [127.0.0.1]) by orion.fa.tdktca.com (8.6.12/8.6.9) with SMTP id GAA06649; Tue, 18 Jun 1996 06:29:45 -0500
Message-ID: <31C69327.32639FD9@fa.tdktca.com>
Date: Tue, 18 Jun 1996 06:29:43 -0500
From: Alex Nash <alex@fa.tdktca.com>
Organization: TDK Factory Automation
X-Mailer: Mozilla 2.0 (X11; I; Linux 1.2.13 i586)
MIME-Version: 1.0
To: bmk@fta.com
CC: "Eloy A. Paris" <Eloy.Paris@ven.ra.rockwell.com>, questions@FreeBSD.org,
        hardware@FreeBSD.org, hal@wwa.com
Subject: Re: FreeBSD works with Cy486DLC processors?
References: <199606180348.UAA01232@everest.dtr.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-hardware@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.

Alex