lee@unmvax.UUCP (12/27/84)
Subject: Berknet on a dh crashes the system
Index: .../sys/h/bk.h
.../sys/vaxuba/dh.c .../sys/sys/tty.c .../sys/sys/tty_bk.c 4.2BSD
Description:
We have two DH lines dedicated to berknet. These are used
fairly heavily. The machine (a 780) cannot stay up for
more than ten days. The crash is always on the line
*tp->t_cp++ = c;
at the instruction
cvtlb r10, *4(r11)
in the BKINPUT macro from .../sys/h/bk.h
No crash dumps are taken; nor are the disks synched. Just
alot of "protection fault" panics and then a reboot.
It looks like the buffer gets deallocated.
However, I cannot find where this might be happening.
We have other machines using berknet on DZ's and they have
never had the problem. Strange...
Repeat-By:
Got me!?
Any help in, either the form of a fix or in modifying the routines
involved in a crash so that I can get a dump would be appreciated.
--
--Lee (Ward)
{ucbvax,convex,gatech,pur-ee}!unmvax!leeBostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa> (12/29/84)
Just as a vote of confidence, I too run a 780 4.2bsd w/ DHs. I put up berknet and the system crashed almost immediately. It was a while back and I didn't really need it (I wrote a remote laser printer spooler for our 20 over RS232 which could take advantage of the berknet low level stuff if it worked.) I too would be interested in fixes etc. -Barry Shein, Boston University
henry@utzoo.UUCP (Henry Spencer) (12/30/84)
Don't get your hopes too high. Somebody (George Goble??) at Salt Lake
said "the only fix for 4.2 Berknet is to unplug it".
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henrylee@unmvax.UUCP (01/03/85)
I have had some inquiries and TWO fixes. So, a followup:
The first fix, from Kirk Smith at Purdue (summmarized):
Though We have not had any crashes we have seen some bizarre
behavior on related (local) disciplines. The fix is to
seperate the clist pointers from the mbuf pointers in tty.h.
Just make them two structures instead of a union of two.
The second from Jim Madden at San Diego State:
One possible cause of this is that the distributed 4.2 Berknet driver,
bby_bk.c, includes code that attempts to disallow certain ioctl calls
once the bk line discipline has been invoked by looking at a "type"
code included in the definition of the ioctl values in sys/ioctl.h.
Unfortunately, the tty_bk.c test fails to properly isolate the type
code field from the rest of the word where it resides and will allow
some calls that it ought to prevent. The most dangerous such call is
TIOCFLUSH which will deallocate various buffers while the driver is
using them and produce a system crash. Here we experienced such
crashes when someone accidentally used the stty command against a
berknet line (eg. stty > /dev/linka).
A fix is attached.
Jim Madden
UCSD Network Services
sdcsvax!madden
*** /tmp/,RCSt1004206 Wed Jan 2 16:18:18 1985
--- tty_bk.c Mon Mar 12 16:40:22 1984
***************
*** 143,149
caddr_t data;
{
! if ((cmd>>8) != 't')
return (-1);
switch (cmd) {
--- 143,149 -----
caddr_t data;
{
! if (((cmd>>8)&0xff) != 't')
return (-1);
switch (cmd) {
The one from Jim Madden was pretty much the same one that I was looking
for but could not find. We have no anamolous behavior at all. Just the crashes.
When I first started looking I was pretty sure that it was an ioctl and looked
at the same piece of code. Obviously, not carefully enough. This *looks*
like the cure for us but I have not tested it yet. Hope these help the
other people who mailed me. Thank you Kirk Smith and Jim Madden, very
much. If any more ideas come in I will accept them happily.
Thanks for everybodies help and time,
--Lee
--
--Lee (Ward)
{ucbvax,convex,gatech,pur-ee}!unmvax!lee