Xref: utzoo comp.unix.ultrix:921 comp.dcom.modems:3816 comp.sys.dec:1265 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!rutgers!cbmvax!grr From: grr@cbmvax.UUCP (George Robbins) Newsgroups: comp.unix.ultrix,comp.dcom.modems,comp.sys.dec Subject: Re: Heard of this modem/vax/ultrix/whoknows problem? Message-ID: <6867@cbmvax.UUCP> Date: 14 May 89 12:36:54 GMT References: <45025@peregrine.peregrine.com> Reply-To: grr@cbmvax.UUCP (George Robbins) Distribution: na Organization: Commodore Technology, West Chester, PA Lines: 63 In article <45025@peregrine.peregrine.com> kirk@moc.Jpl.Nasa.Gov writes: > Posted for a friend: > > From: Kirk Reinholtz > > 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@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)