From: Terry Lambert [mailto:tlambert2_at_mindspring.com] > Don Bowman wrote: > > This may be a dumb question, but I have > > a situation where machine A and B both have > > enabled serial console. I'm ssh'ing into A to > > try and debug a problem on B. I'm trying to > > use tip, but am getting interference from the > > fact that A also has a serial console. > > > > If i disable the getty, its a bit better. > > > > Is there a way to make this work reliably, or > > am I SOL? > > Use or modify a getty to require multiple CR's to activate. Or > use one that only activates on a break. > > Best would be to use a getty that respected lock files, needed > 2 CR's to start after off-to-on DTR/DCD transition (you will be > using a NULL-modem cable), and your tip/cu/whatever program did > appropriate locking, and knew how to back off. > > Then you could put the getty's back-to-back and they would not > chat each other to death, and you could call out of the one > machine into the other, and your local getty would not eat half > the characters. > > See also "uugetty" and "mgetty" in ports. What i ended up doing which worked OK was to changed /etc/ttys on the machine i wanted to run tip on to comment out the 'ttyd0' line, and HUP init. I then installed 'minicom' port, and used it. The machine i was running it on has to be quiescent so no kernel printfs occur. minicom used /dev/cuaa0. Bruce Evans suggested using 'db' to poke a '0xc3' into the kernel printf start to make it return right away, if this were a bigger problem for me I would give that a try. --donReceived on Wed Sep 17 2003 - 04:36:02 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:22 UTC