Unix Technical Digest V2 #17

Heiby netnews at wnuxb.UUCP
Fri Sep 13 01:58:29 AEST 1985


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: <hplabs!hp-pcd!orstcs!hakanson at orstcs>
Subject: rwhod not working

    Date:  Sat, 31 Aug 85 17:33:49 edt
    From:  Chris Torek <chris at MARYLAND>
    To:  hakanson%oregon-state at 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 at csnet-relay
                        UUCP :  {hp-pcd,tektronix}!orstcs!hakanson

------------------------------

Date: Fri, 6 Sep 85 22:51:54 edt
From: Kevin Szabo <ihnp4!watmath!watvlsi!ksbszabo>
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 at wnuxb.UUCP
AT&T Information Systems, Inc., Lisle, IL  (CU-D21)



More information about the Mod.unix mailing list