Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!ames!ucbcad!ucbvax!sdcsvax!ucsdhub!jack!crash!ford From: ford@crash.cts.com (Michael Ditto) Newsgroups: comp.sys.att Subject: Re: PC7300 refuses to echo characters Message-ID: <2170@crash.cts.com> Date: 20 Dec 87 20:26:41 GMT References: <653@astroatc.UUCP> Reply-To: ford@crash.CTS.COM (Michael Ditto) Organization: Crash TS, El Cajon, CA Lines: 61 Keywords: serial port, getty, tty000, lossage, keyboard, echo Summary: I have seen Unix PCs do this when bombarded by tty000 input In article <653@astroatc.UUCP> mag@astroatc.UUCP (Michael A. Goldsmith) writes: >After it has been running for a while (amount of time varies), the >system refuses to echo some characters typed on the console. It may >take several hits of the same key to get that key to echo. Even more >peculiar, some (but not all) of the un-echoed keys are nevertheless >received by the shell. I have two Unix PCs at work, sitting next to each other. They work fine normally, but I can produce exactly the results you describe by connecting a cable between their serial ports while a getty is running on both of them. This is obviously not a good thing to do, but it seems to have a particularly drastic effect on the Unix PC. The reason it is bad is that each computer is echoing everything sent by the other one, plus inserting its own messages (like "login incorrect"). The result is that both ports are sending and receiving at full capacity and both the receive and transmit buffers are constantly overflowing. This can slightly slow down any Unix machine, but the Unix PC seems to completely choke in this situation. The communication interrupt is a higher priority than the keyboard interrupt, so it's understandable that keystrokes could be lost, but it is very strange that sometimes the key is read but not echoed (And you can't lose characters going to a bit- mapped display). I suspect that it may be related to the fact that the korn shell does its own echoing. (Are you using ksh? Emacs mode or vi?) Anyway, the fix is to do one of the following: Get rid of the getty on tty000. ("setgetty 000 0" will do this). Get rid of whatever is plugged into tty000, or make it stop sending characters. If you take the first approach, you may have a fight with the phone manager, which likes to fiddle with the inittab every once in a while. This just means you may have to run the setgetty command after each reboot, or whenever you use the phone manager, or something. I got rid of the phone manager on my system, so I don't have that problem. The second approach depends on what your serial port is connected to. If it is connected to another computer, make sure that either the other system is accepting logins (i.e. has a getty running) OR that yours is, but NOT BOTH. An alternative is to make both systems run "uugetty" (or a similar program) which will not send any characters until someone attempts to log in. If you have a hayes-like modem plugged in to tty000, make sure it is not in "command echo mode". There is probably a dip switch for this, or send it "ATE0". By the way, "ps -e" always pauses after the first four processes, it's just more noticable when the system is bogged down like that. Good luck. I hope you get your problem fixed. -- Mike Ditto -=] Ford [=- P.O. Box 1721 ford%kenobi@crash.CTS.COM Bonita, CA 92002 ford@crash.CTS.COM