Path: utzoo!utgpu!water!watmath!clyde!rutgers!mailrus!umix!husc6!mit-eddie!uw-beaver!cornell!rochester!bbn!uwmcsd1!ig!agate!ucbvax!CITHEX.CALTECH.EDU!carl From: carl@CITHEX.CALTECH.EDU (Carl J Lydick) Newsgroups: comp.os.vms Subject: Re: Wild processes Consuming CPU Message-ID: <880208020917.232@CitHex.Caltech.Edu> Date: 8 Feb 88 10:20:41 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 46 > Yes, on a VT100 connected via 500 ft of cable to a 780 using all modem control > lines. The user switches his terminal off without logging off (staying in DCL). > Then the process starts using around 6% of the available CPU time (absolutely > constant, not just on the average) and creating several IOs per second. As the > process is using CPU time, it is not going to be automatically terminated by > the WATCHER program. > > The funny part is: there is no image being executed, it is just DCL; but the > CPU time is being used in USER mode, not on the interrupt-stack, or in kernel > mode. To cure the problem, i just switch the terminal back on, it immediately > stops using CPU time, and it is still in DCL. Also, if the user logs out BEFORE > switching the terminal off, nothing funny happens. > > All this happens only with this one terminal, using this one cable, but > on any port with modem control lines. > > We don't really understand the problem, but i have the following theory: When > the terminal goes off, its V24 line drivers are not actively driving the modem > control lines any more, so they pick up electrical noise. Actually, we can see > a lot of AC noise on all the output lines of this terminal (around 2V p-p). > Maybe the input lines on the VAX port are too sensitive, and actually register > the noise as being modem control lines changing their state at around 60 Hz, > and this drives the terminal driver crazy. I just don't understand how logging > off could cure this problem. But probably my theory is completely wrong. We've had a similar problem here. First: Note that your cable doesn't conform to the specs for RS232 communications (it's about 10 times longer than the specs allow), but since most RS232 interfaces are overdesigned, such cables are not generally a problem. In our case, the problem was with a 3-conductor cable to an H19 terminal in the basement (our computer's on the 2nd floor). The user owning the terminal tended to turn off the terminal without logging out. The result was that the (now unterminated) cable seemed to have enough coupling between the input and output lines that any character sent to the terminal resulted in some character being sent to the VAX. This meant that when a job was still logged in, we got LOTS (your 6% CPU usage sounds a little low) of chatter on that line. The reason, in our case, was that, with a process logged in, everything apparently sent from the terminal got echoed back, resulting in further noise on the line, which caused more echoing from the VAX, etc. Without a job logged in on the line, there was no echoing (actually, a control-y or control-m would have started a loginout, but those characters were NOT generally generated by noise on the line). We had a similar problem on a line from somebody's PC to a laser printer. You might try putting a resistor between signal ground and the transmit data pin on the terminal as a solution if you can't get the user to log out before turning off the terminal.