Another issue that may be interesting:
Is this a server-like PC where you can tweak the serial console
usage from the BIOS?
I saw strange behaviour on a HP ProLiant DL145 G2 (I think) where
for some configuration of the serial BIOS console, the login
promp from OpenBSD on the serial port came and went depending on
if I attached to the telnet-emulated-through-BIOS serial console
through the Integrated Lights-Out ethernet connector.
Bottom line. Are there interesting BIOS settings for serial console?
On Wed, May 30, 2007 at 11:30:56AM -0400, Woodchuck wrote:
> On Tue, 29 May 2007, Maurice Janssen wrote:
>
> > Hi,
> >
> > I'm trying to use a VT420 serial terminal on an i386 box running
> > 4.1-stable. Not as a system console, just as an extra screen to login.
> > The output of the boot loader and kernel output should go to the
> > monitor, as usual.
> >
> > The terminal is hooked up to the first serial port with a null modem
> > cable. I changed the tty00 line of /etc/ttys to:
> > tty00 "/usr/libexec/getty std.9600" vt220 on secure
> > and sent -HUP to init. There's a getty process on tty00, but there's
> > no login: prompt on the terminal. Everything I type on the terminal is
> > echoed on the screen, so the cable is OK (local echo is off).
>
> HMMMM. Look into two things, no, make that three:
>
> 1) The settings on the terminal, whether XON/XOFF or RTS/CTS
> synchronization is selected, also baud rate, parity, 8/7 bits. Try
> 8 bits, No parity, 1 stop bit ("8N1").
>
> 2) The settings on the tty, from # stty -a /dev/tty00 when
> the getty is running.
>
> 3) There are null modem cables, and there are null modem
> cables. Some are just plain junk, providing only cross over of the
> two data pins and if you're lucky, a ground. Others implement
> various ideas of what a null modem cable should be; the opinions
> of what a null modem cable differed between Digital, who made your
> terminal and IBM, who designed the PeeCee.
>
> > The funny thing is, when I start 'tip tty00' on the machine (while
> > logged in at the keyboard+monitor), the login: prompt appears on the
> > terminal.
>
> Yeah, this is weird. You should be able to get the login: prompt
> by at most hitting the carriage return on the 420 twice. Try to
> set up everything for XON/XOFF flow control.
>
> > When I quit tip, I can login at the terminal. When I logout from the
> > terminal, the login: prompt doesn't appear (but everything I type is
> > echoed to the terminal screen as before). I can start tip again, and
> > then the login: prompt shows up again.
> >
> > I suspected a problem with the permissions of the tty00 device. After
> > logout, they are set to
> > crw------- 1 root wheel 8, 0 May 29 21:44 tty00
>
> This, by default, should be uucp.dialer, permissions crw-rw---,
> when "at rest". When a getty is running, it should be as shown here.
>
> > When logged in it is set to
> > crw------- 1 maurice tty 8, 0 May 29 22:00 tty00
> > Not sure if this is what it should be, but it doesn't look strange to
> > me.
> >
> > BTW: not sure if it is related, but when I login as normal user, the
> > following warning is shown on the terminal:
> > ksh: No controlling tty (open /dev/tty: Device busy)
> > ksh: warning: won't have full job control
> > When I login as root, I don't get this warning.
>
> Ick. I have my suspicions, but won't voice them since they are
> superstitious. They involve a brief trip to single-user mode and
> running cd /dev; sh MAKEDEV all.
>
> > Any ideas what's going wrong?
>
> Yeah, you're using a serial terminal on a PeeCee. (sarcasm).
>
> You are in a maze of twisty little passages, all alike. The
> lamp grows dimmer. (Zork, a metaphor for debugging RS-232).
>
> Install a terminal emulator on the box, like kermit or something
> like minicom, from ports if the sometimes goofy behavior of tip/cu
> annoys you (like killing its parent xterm when you give it ~.).
> Hook up the terminal. See what you can do. Try things (settings).
> Terminals are a PITA, as bad as serial printers. See if the 420
> has a VT-220 emulation mode, if so try it. It's hard to debug them
> "over the phone" (by email) like this, one needs to poke and try.
> A RS232 line analyzer is real handy. There used to be various
> utilities for MS-DOS that would display line status of the com ports
> on the screen, much like the blinkenlights on a modem. Don't know
> it they exist for Unix. Could kermit have such a feature? One has
> to delve into the kernel to see these things, a forbidden zone in
> Unix, unless some happy ioctl to pccom exists.
>
> Helpful man pages: tty, tip, remote, cu, getty, gettytab, pccom
>
> With the getty killed, try catting a "large" text file to
> /dev/tty00 (as root), look for garbage on the terminal, a sign
> of flow control being wrong. Try this with the terminal set
> for "smooth scrolling".
>
> A debugging test: use the same cable (if you can) and connect
> the com ports of two OpenBSD boxes. Start the getty on one, and
> use tip/cu/minicom/kermit on the other. Everything should work
> fine. If it doesn't, the cable sucks in some way. If it doesn't
> work, force XON/XOFF on both boxes. How you do this for getty is
> a good question, settings in gettytab is the answer.
>
> Dave "I already have a headache, and it's not my problem!"
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
