RE: using tip on machine that has COMCONSOLE set to serial
From: Terry Lambert [mailto:[EMAIL PROTECTED] > 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. --don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: using tip on machine that has COMCONSOLE set to serial
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. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: using tip on machine that has COMCONSOLE set to serial
On Tue, 16 Sep 2003, 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? Not completely reliably. In -current you can try switching off the serial console, but IIRC the switching code has problems in precisely this area -- it doesn't turn off the lowest levels of consoleness. Turning off getty is a good idea. cua* with getty on ttyd* may work, but it is necessary to turn off CLOCAL on the console snd maybe fiddle with carrider on the line so that getty blocks in open. CLOCAL defaults to on for serial consoles and is locked on. Speeds are also locked for consoles. Turning off anything that writes to the console (e.g., syslogd) is a good idea if you haven't turned off the console. I sometimes turn off low level writes by writing machine code in ddb. On i386's, writing byte 0xc3 at printf turns off all kernel printfs (fortunately nothing checks their return value :-). Overwriting byte 0xe8 with byte 0xb8 in calls to printf turns off individual printfs. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
using tip on machine that has COMCONSOLE set to serial
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? --don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
