From owner-freebsd-hardware  Tue Apr  2 23:16:03 1996
Return-Path: owner-hardware
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id XAA29345
          for hardware-outgoing; Tue, 2 Apr 1996 23:16:03 -0800 (PST)
Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA29258
          for <freebsd-hardware@freebsd.org>; Tue, 2 Apr 1996 23:15:50 -0800 (PST)
Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id XAA04935; Tue, 2 Apr 1996 23:13:58 -0800
From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com>
Message-Id: <199604030713.XAA04935@GndRsh.aac.dev.com>
Subject: Re: Parity Errors
To: msmith@atrad.adelaide.edu.au (Michael Smith)
Date: Tue, 2 Apr 1996 23:13:58 -0800 (PST)
Cc: dave@persprog.com, freebsd-hardware@freebsd.org, cschuber@orca.gov.bc.ca
In-Reply-To: <199604030042.KAA16695@genesis.atrad.adelaide.edu.au> from Michael Smith at "Apr 3, 96 10:12:10 am"
X-Mailer: ELM [version 2.4ME+ PL11 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hardware@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> David Alderman stands accused of saying:
> > 
> > 
> > > FreeBSD can't generate NMI signals; it's your motherboard hardware that's
> > > doing that.  It wouldn't surprise me if Linux just ignored them 8) 
> > > 
> > I've seen NMI's come out of motherboards from problems other than 
> > main RAM.  Sometimes noise or other problems can cause NMI's with 
> > poor motherboard designs.  I seem to remember stray DMA requests can 
> > sometimes trigger an NMI.  
> 
> Yup, yup and it wouldn't surprise me 8)
> 
> > Has anyone seen parity on the cache?
> 
> Not on a PC motherboard...
> 
> > It's probably not FreeBSD to blame - it is more likely FreeBSD is 
> > revealing a latent weakness in your system.
> > Does anyone remember if NMI is brought out to the ISA bus?  This 
> > would open up all kinds of possibilities.
> 
> No; according to Solari it isn't, but IOCHCHK is just as bad (one of the
> spurious-NMI boards I have generates these too - I think it must just be 
> bored...)

~IOCHCK (ISA bus signal, pin A1) is one source of NMI, if this is the
source of an NMI it is noted in bit 6 of port 0x61.  See src/sys/i386/isa/isa.c
at or near lines 807 and 826 (grep for NMI_IOCHAN).

And I just noticed a major boo boo in isa_nmi(), we should really print
the the ``NMI ISA %x, EISA %x'' with a bit field interpretation, and then
call panic with a string like ``NMI, likely hardware failure''.

As it is currently written it will flag one of the sources, but more than
one of them may be set for broken hardware (I have seen hardware that sets
the PARITY bit along with the IOCHCK bit :-().

-- 
Rod Grimes                                      rgrimes@gndrsh.aac.dev.com
Accurate Automation Company                 Reliable computers for FreeBSD