[comp.sys.att] Open

naim@nucsrl.UUCP (Naim Abdullah) (11/17/87)

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.

wjz@ihlpf.UUCP (11/21/87)

In article <3540001@nucsrl.UUCP>, naim@nucsrl.UUCP (Naim Abdullah) writes:
> 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.
                                                                       ^^^
> 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.
> 
> 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.


Naim,

I am not sure, but the resolution to your "bug" may be to install
the correct version of 3BNET in your machine. There is a way to tell.
Here's how:

	1. If you did not upgrade 3BNET when you went to 3.1 from 2.1,
	then you should.

	2. Slide your 3BNET distribution disk in the diskette drive
	and close the lever (turn it downward).

	3. Type "mount /dev/diskette /mnt -r" (Don't type in the
	quotation marks)

	4. cd to /mnt/new

	5. See if there are two subdirectories under "new"
	named SVR2.0 and SVR3.0. If there are, then you have the
	right version of 3BNET and your problem is something else.

	6. Look at the date stamps of some of the 3BNET files.
	They should be dated Feb 4 1986 to operate with SVR3.

That should do it. If it does, please remember to post to those
other newsgroups that you had an installation problem, not a bug
in the code.

Bill Zimmerman, ihnp4!ihlpf!wjz