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