Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!uwvax!oddjob!gargoyle!ihnp4!chinet!nucsrl!naim
From: naim@nucsrl.UUCP (Naim Abdullah)
Newsgroups: comp.sys.att
Subject: Open(2)'ing /dev/ni causes Kernel Panic in 5.3.1
Message-ID: <3540001@nucsrl.UUCP>
Date: Mon, 16-Nov-87 21:50:25 EST
Article-I.D.: nucsrl.3540001
Posted: Mon Nov 16 21:50:25 1987
Date-Received: Sat, 21-Nov-87 19:50:49 EST
Organization: Northwestern U, Evanston IL, USA
Lines: 38

I have run across a kernel device driver bug in System V, rel. 3.1
on ATT 3b2s. The bug is that opening /dev/ni for writing causes
a kernel panic. This is the documented way of sending data over 3BNET
and now that it causes a panic, I don't know what else to use for
sending packets over 3BNET. Note that this used to work fine in rel. 2.1.
I only discovered that it no longer worked, when we upgraded to rel. 3.1.
Here is a one liner that causes a panic (you can run this from any account).

main(){ return(open("/dev/ni", 1)); }

Running this gives:
TRAP
proc= 401CDCC0 psw= 280072B
pc= 4002AE74
PANIC: KERNEL MMU FAULT (F_ACCESS)

Please don't flame me for posting this program to cause the crash. If your
machine has this bug, I think you should know about this. Just turn off
write permissions on /dev/ni if you don't want Joe User to crash your
machine.

The strange thing is that nisend(1) continues to work fine. I wonder how
it sends data over 3BNET ?

Anyway, has anybody discovered any workarounds ? We have 5.3.1 sources so
bug fixes are welcome.


		      Naim Abdullah
		      Dept. of EECS,
		      Northwestern University

		      Internet: naim@eecs.nwu.edu
		      Uucp: {ihnp4, chinet, gargoyle}!nucsrl!naim

P.S: Notes cannot cross-post (yet), so I have posted copies of
this article in comp.unix.wizards, comp.unix.questions, comp.sys.att.
So you may see this article more than once.