Heard of this modem/vax/ultrix/whoknows problem?

[George Robbins]

In article <45025 at peregrine.peregrine.com> kirk at moc.Jpl.Nasa.Gov writes:
> Posted for a friend:
> 
> From: Kirk Reinholtz <elroy!moc.Jpl.Nasa.Gov!kirk>
> 
> Have you seen or heard, on net news perhaps, any discussion of problems
> with modems (esp Hayes 2400bps) on 3.0 ultrix on microvaxII, DHV
> interface board?  The problem is that sometimes when carrier is dropped
> by the remote site w/o the remote site first doing a kill on whatever
> shell it has on the local machine the modem shows Rx and Tx lites
> constant on and the vax either stops providing cycles to the users (but
> does not crash) or gets quite sluggish.  The modem is configured
> "shared": used for both dialin and dialout.

Hard to tell where to start...  First make sure the modem is configured
so it doesn't echo in command mode.  Second have it set up so that
dropping DSR forces it to hang up and, if possible, ignore input.  Finally,
make sure it is set up so that it drops CD when when a call is terminated
and does not assert CD when when in "command mode".  Also insure that
modem control is not being disabled between the "flag" in the system
configuration file and the stuff in /etc/ttys.

Between these things you should be able get the thing under some kind of
control.  The ultrix shared lines stuff gets real twitchy if the modem
isn't playing the game right.  It doesn't help that there isn't a clear
description anywhere of how the shared modem stuff works...

It's actually pretty simple.  Init starts a getty for each line.  The
getty does an open, blocking waiting for for carrier detect. If a call
comes in, CD is asserted, the open completes and getty proceeds to do
it's tricks and start up a login.  If uucp or tip want's the modem,
they do an ioctl to request exclusive control of the line.  This
apparently blows off getty's open with an error return and uucp/tip
owns the line until they close it, at which time getty's attempts to
open the line stop failing immediately and it gets to the wait for
CD mode again.  If a call has already come in, getty isn't sitting at
the open/wait for CD point and uucp/tip's attempt to get exclusive control
fails.

Obviously, for this to work properly, the modem has to drive CD according
to whether there is an incoming call and not confuse things with asserting
CD in command mode...

By the way, though it isn't mentioned anywhere, with the (wretched) DMF32,
the driver seems to contain kludge code to make it interpret DSR as if
it were really CD, so in this case you should set up your smart modem
to always assert CD, and to have DSR relflect whether there is a call
in progress.  Theoretically (!) this lets you get around all the problems
caused by the DMF32 having a fascist CD that blocks input at the hardware
level.

I haven't verified the above completely, it just sort of fell out when
I was trying how to get the shared line stuff to work with a 3-rd party
DH11 emulation that didn't support DSR...  After a good solid whack on
the head it became obvious that the DMF driver was the wierd party and
CD was all that mattered on other interfaces...  It appears that there
is a global variable, dmfdsr, that can be set to 0 with adb if you
really want to disable this bizarre action in the DMF driver.

-- 
George Robbins - now working for,	uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr at uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)