mag@astroatc.UUCP (Michael A. Goldsmith) (12/15/87)
I recently upgraded my 2 year old 7300 from release 3.00 to 3.51. The upgrade went smoothly and I followed all instructions regarding the removal and re-installation of Installed Software. However, the system now exhibits an annoying behavior: 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. If it stops echoing keys, waiting a few seconds and then continuing to type makes the problem go away for a few more seconds; then it recurs. Other observations: The mouse tracks properly, but button presses are often ignored. The 'ps -ea' command pauses for about 1/2 second part way through its output. Each successive repetition of the 'ps -ea' command consumes about 1 second of CPU time in process #3, windowdaemon (Having never needed to check before, I have no idea if this is normal. I suspect that 1 sec is excessive). There is apparently no observable (at least that I've been able to determine) correlation between the system beginning this behavior and any of the following: 1. Particular keys typed. 2. Amount of time system has been up. 3. What command or commands have been used since system boot. The only (temporary) fix for the problem is a reboot. Does anyone have any ideas to help? Thanks in advance Michael A. Goldsmith Astronautics 5800 Cottage Grove Rd. Madison WI 53704 608-221-9001,x117 ...uwvax!astroatc!mag
wtm@neoucom.UUCP (Bill Mayhew) (12/17/87)
1. I am running ver. 3.51 foundation set & utilities
2. I *do* have the communications patch installed
3. Timing of the lock-up is unpredictable. The first time
was 3 days after I got the machine. The second time was
about a week after that. The last time, the machine was
rebooted on Nov. 21, 1987 and ran until Dec. 15, 1987.
4. A good test is when the slow-down happens, try tail
/etc/termcap. The display will freeze every 4 or 6 lines
of output. Pressing any ascii key will restart output.
The keystrokes are received by the shell as is evidenced
by garbage prepended to the next command typed at the shell
prompt.
5. Telinit -Q or kill -1 1 don't have any noticable effect.
6. ps -fe doesn't show anything out of the ordinary.
7. I think the problem might be related to the ph process.
The crashing seems to happen an hour or two after there has
been a uucp login on ph0.
8. I don't run any weird daemon programs. I gave phdaemon the
boot after the AT&T help line insisted that since it was
the only non-AT&T thing running it must be to blame.
9. If you provoke the system by continuing to type stuff during
the brain-stroke period, the system will die completely,
requiring use of the dreaded black reset button in back.
10. One time the slowness happened, I left the machine alone for
about an hour to meditate with itself. The slowness appeared
to heal itself. (Only a minor clot in a little artery, I
suppose.)
11. There aren't any messages left behind in unix.log.
--Billford@crash.cts.com (Michael Ditto) (12/21/87)
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