*BSD News Article 76758


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!spool.mu.edu!usenet.eel.ufl.edu!news.mathworks.com!fu-berlin.de!informatik.tu-muenchen.de!Germany.EU.net!Dortmund.Germany.EU.net!interface-business.de!usenet
From: j@ida.interface-business.de (J Wunsch)
Newsgroups: comp.unix.bsd.bsdi.misc
Subject: Re: Strange message on older BSDi system
Date: 23 Aug 1996 09:20:53 GMT
Organization: interface business GmbH, Dresden
Lines: 39
Message-ID: <4vjt5l$b9g@innocence.interface-business.de>
References: <4vhsfcINNop5@duncan.cs.utk.edu>
Reply-To: joerg_wunsch@interface-business.de (Joerg Wunsch)
NNTP-Posting-Host: ida.interface-business.de
X-Newsreader: knews 0.9.6
X-Phone: +49-351-31809-14
X-Fax: +49-351-3361187
X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F  93 21 E0 7D F9 12 D6 4E

jfarmer@cs.utk.edu (JOHN FARMER) wrote:

> Aug 22 02:31:38 sabre kernel:
> Aug 22 02:31:38 sabre kernel: NMI port 61 b0, port 70 ff
> Aug 22 02:31:44 sabre root: Configuration changed:
> Aug 22 02:31:44 sabre root: 36c36
> Aug 22 02:31:44 sabre root: < NMI port 61 a0, port 70 ff
> Aug 22 02:31:44 sabre root: ---
> Aug 22 02:31:44 sabre root: > NMI port 61 b0, port 70 ff

The ``port 61'' and ``port 70'' messages are entirely useless.  They
have probably been correct for some weird notebook (they are at least
for mine, but it's a 1991 386sx/16 type box), but they have *never*
been correct for any mainstream hardware.

The same type of nonsense was lurking around for too long in the
386BSD kernel sources, so i figure both have got the same ancestors.
(Bill Jolitz?  I seem to remember that he did much of his initial work
on a notebook.)

Port 0x61 is indeed related to NMI handling, but only as a _control_
port.  Bit 0x10 enables RAM parity error reporting, bit 0x20 enables
IOCHCK NMI generation.  Port 0x70 bit 0x80 allows to mask off NMIs
entirely, but it is not possible to read it back.  Port 0x62 allows to
diagnose the source of the NMI: bit 0x40 is set for an IOCHCK (ISA bus
signal [*]) generated NMI, bit 0x80 is set for a RAM parity error
caused NMI.

It's rather obvious from your description that your memory is bad.
It's a bug in your kernel that it doesn't panic() the entire system.

[*] If your kernel handles NMIs properly, IOCHCK can be hooked to a
pushbutton on the ISA bus, and used to force the kernel going to DDB
even if maskable interrupts are disabled.

-- 
J"org Wunsch					       Unix support engineer
joerg_wunsch@interface-business.de       http://www.interface-business.de/~j