dmi@peregrine.com (Dean Inada) (05/14/89)
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. TAS put a scope on it and found that the vax was emitting a "Z" every 10ms at the modem, which naturally echoed it back. The modem was 2400bps at the time. This is not the normal getty shouting at modem problem: the shell on the line does not gather CPU time and does not constantly die and then come to be reborne. We swapped modems, we swapped DHV, we even swapped brand of modem: no substantial impact on the problem, though it does seem like the hayes is more vulnerable to the malfunction than the other modem we tried (Telebit). Thanks! kirk@mocvax
grr@cbmvax.UUCP (George Robbins) (05/14/89)
In article <45025@peregrine.peregrine.com> kirk@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@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
wtm@neoucom.UUCP (Bill Mayhew) (05/16/89)
This sounds like the classic getty-babble problem. This happens when the modem has command echoing enabled on a dial-in line. When the new getty forks, the modem gets some character, which it then echos back to the host port because the modem is in command mode after the call completes. The simplest solution to the problem is to use the line for dial-in only, and disable command echoing permanently via the dipswitch so that when getty issues the prompt string, it won't be echoed by the modem .. essentially the hardware analogy of ATE0Q1. You need to have Q1 set (via dipswitch too if possible) so that when the modem answers that it doesnt send RING into getty, causing getty to send back Password: before the carrier handshake has completed.. this will cause the modem to hang-up the call. It seems that even if you have ATE0Q1 set by hardware dispswitches, most modems go into getty-babble on occasion anyway. I deal with that by running a script that looks for a lock file and/or port being owned by root every 1/2 hour. If the port is owned by root and no lock file exists on the port, I kill the getty which in turn forces the modem control leads (which you wired up, right?) low which again in turn forces the modem into a sane state (hopefully). Getty babble is usually accompanied by a very high load on the system due to the fact that the login process runs at a high priority. If you're using the port to dail out as well as in, your outgoing chat script shoud issue a couple of ATZs separated by a /p to clear the modem, then send it an ATE1Q0 to enable command echoing for the duration of the current call. It is a pain to try to use a port for both dial-in and dial out without HoneyDanBer uucp. Apologies if my diagnosis is wrong, but it sure sounds like getty-babble. I don't know about the DHV, but the DH and DZ interfaces are a real pain in the neck because you one gives you modem control, but no flow control, while the other has flow control but no modem control. Bill wtm@impulse.UUCP