From owner-freebsd-hackers  Mon Jul 17 00:15:29 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id AAA07358
          for hackers-outgoing; Mon, 17 Jul 1995 00:15:29 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA07335
          for <hackers@freebsd.org>; Mon, 17 Jul 1995 00:15:15 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA22674; Mon, 17 Jul 1995 17:09:23 +1000
Date: Mon, 17 Jul 1995 17:09:23 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199507170709.RAA22674@godzilla.zeta.org.au>
To: esser@zpr.uni-koeln.de, yenbut@cs.washington.edu
Subject: Re: One cause of 2.05R instability found
Cc: hackers@freebsd.org
Sender: hackers-owner@freebsd.org
Precedence: bulk

>A few days ago, my system (the kernel has the if statement in ncr.c commented 
>out) crashed twice after it has been running fine for almost a week:

It seems to be just flaky hardware.

>Fatal trap 12: privileged instruction fault while in kernel mode
>instruction pointer    = 0x8:0xf0128e83
>code segment           = base 0x0, limit 0xfffff, type 0x1b
>                       = DPL 0, pres 1, def32 1, gran 1
>processor eflags       = interrupt enabled, resume,  IOPL = 0
>current process        = 13345 (nntpd)
>interrupt mask         =
>kernel type 1 trap, code = 0
>stopped at _lookup + 0x11b: lcall *%edi


I had an interesting crash like this.  I was running one of my systems
in non-turbo mode to serial test overload conditions.  It crashed on
a privileged instruction.  Examining nearby memory using ddb showed
that there was a single bit error in the instruction.  I restored
the bit and continued successfully.  This system has the "slow refresh"
option set to as slow as possible and I guess that using this violates
the memory specs more when the system is in non-turbo mode.

Bruce