Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site wnuxb.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!mgnetp!hw3b!wnuxb!netnews From: netnews@wnuxb.UUCP (Heiby) Newsgroups: mod.unix Subject: Unix Technical Digest V2 #17 Message-ID: <633@wnuxb.UUCP> Date: Thu, 12-Sep-85 11:58:29 EDT Article-I.D.: wnuxb.633 Posted: Thu Sep 12 11:58:29 1985 Date-Received: Fri, 13-Sep-85 04:27:46 EDT Reply-To: unix@cbosgd.UUCP Organization: AT&T - Warrenville Data Center, IL Lines: 102 Keywords: rwhod, NULs hang 785 Approved: netnews@wnuxb.UUCP Really-From: Ron Heiby (The Moderator) Unix Technical Digest Thu, 12 Sep 85 Volume 2 : Issue 17 Today's Topics: rwhod not working Terminal spewing NULs at 9600 bps hangs 785 ---------------------------------------------------------------------- Date: 03 Sep 85 18:09:36 PDT (Tue) From: Subject: rwhod not working Date: Sat, 31 Aug 85 17:33:49 edt From: Chris Torek To: hakanson%oregon-state@CSNET-RELAY Subject: Re: rwhod not working I would suspect that you haven not fixed either ifconfig or your kernel. A bug in the kernel allows all the flags to be set (instead of just UP, NOARP, TRAILERS), and ifconfig doesn't know that so it simply sets new flags without examining the previous state. There are two ways to fix it; the (clearly superior) method is to fix the kernel code the same way Berkeley did. Here is the new code in /sys/net/if.c, case SIOGSIFFLAGS: #define IFF_CANTCHANGE (IFF_BROADCAST | IFF_POINTOPOINT | IFF_RUNNING) case SIOCSIFFLAGS: if (ifp->if_flags & IFF_UP && (ifr->ifr_flags & IFF_UP) == 0) { int s = splimp(); if_down(ifp); splx(s); } ifp->if_flags = (ifp->if_flags & IFF_CANTCHANGE) | (ifr->ifr_flags &~ IFF_CANTCHANGE); break; (The IFF_CANTCHANGE definition is actually in if.h, but this is the only place that uses it.) Chris I agree that the fix suggested above is the "right" way, and installed the patch. "/etc/ifconfig il0" now reports that BROADCAST is enabled, which would seem to solve part of the problem. But rwhod still doesn't talk to its counterpart on the other VAX (or vice-versa); compiling rwhod with the DEBUG flag set (and with a few of my own trace statements) shows that both rwhod's are sending the right info to the "who" service (socket), but that neither one is receiving any packets. What's the next step? Give up? Wait for 4.3? At any rate, I really appreciate the help. Marion Hakanson CSnet: hakanson%oregon-state@csnet-relay UUCP : {hp-pcd,tektronix}!orstcs!hakanson ------------------------------ Date: Fri, 6 Sep 85 22:51:54 edt From: Kevin Szabo Subject: Terminal spewing NULs at 9600 bps hangs 785 Our Vax 11/785 running bsd4.2 uses dmz's for I/O. We have an AED512 which sometimes goes into a snit and starts sending NULL's at 9600 baud. This brings all terminal bound I/O to a HALT! The vax doesn't even have enough time to send BELLS to the AED. If I disconnect the rs232 line to the AED and then immediately reconnect it the BELLS sometimes reach the AED. Terminal I/O will also sometimes restart, even though the 9600 baud stream is still blasting at the VAX. We tried this on a vax11/780; I think it has DMF 32's (emulex?), but I am not too sure about it. It also locked up until the stream was momentarily interrupted. Now for the questions... 1) Is this normal behaviour? 2) Is it possible that the vax/11785 + driver cannot sustain a 9600 baud data flow? I should add that nothing was reading the tty so the buffer was guaranteed to overflow. 3) Does anyone know why interrupting the data flow momentarily allows everything to proceed correctly? 4) I imagine there is lots of spl?() magic in the drivers; is it possible that a interrupt lockout bug is lying around in both our DMZ and DMF code? I think they are both standard 4.x distribution. Thanks for any enlightening information. Kevin Szabo Kevin Szabo' watmath!wateng!ksbszabo (U of W VLSI Group, Waterloo, Ont, Canada) ------------------------------ End of Unix Technical Digest ****************************** -- Ronald W. Heiby / netnews@wnuxb.UUCP AT&T Information Systems, Inc., Lisle, IL (CU-D21)