[SOLVED] Serial Connection
On Fri, 01 Apr 2011 06:02:38 -0400 (EDT), MAROUNI Abbass wrote:
>
> Sorry forgot to mention that we are in Paris and the datacenter is in
> Amsterdam. So no physical access to the servers.
For your production environment, perhaps. But you led us to believe
that you had two local servers side-by-side for testing purposes
that were cabled together by means of a cross-over serial cable or a
standard serial cable in conjunction with a null modem. Obviously
you don't have a serial cable running all the way from Paris to
Amsterdam. You're using modems and phone lines, or
ethernet to serial converters, or something similar.
Your comments about the cable were misleading. It seems that you
either won't supply pertinent information or you supply misleading
information.
>
> But good news : I finally made it.
I'm glad you got it working.
>
> Apparently ttyS0 and ttyS1 are different. I had to use baudrate of
> 115200 with vt102 on ttyS0 and a bauderate of 9600 with vt100 on ttyS1.
> is that a software or a hardware issue? I always thought that ttyS0 and
> ttyS1 are the same.
It doesn't matter which serial port is called /dev/ttyS0 and which
serial port is called /dev/ttyS1. What matters is the hardware.
Years ago, I had an old 486 machine with a 16-bit ISA bus. Installed
in one of these bus slots was an 8-bit multi-io card which provided
two serial ports, a parallel port, and a joystick port. This card
was originally designed for PC and PC/XT clones. It used
National Semiconductor (NS) 8250 Universal Asynchronous
Receiver/Transmitter (UART) chips, or their hardware clones.
According to the manufacturer's specifications, the 8250 UART can
operate at speeds up to 56 kilobits per second (kbps). But in actual
practice, I found that 9,600 bps was as fast as it could go. Something
about the design of the support circuitry limited its speed to 9,600 bps.
I don't know what. But if I tried to push it any faster I either got
garbage or dropped characters.
I also used to have an IBM PS/2 Model 70. The UART on its motherboard
is a 16550A. According to the manufacturer's specifications, the
16550A is capable of operating at speeds of up to 256 kbps. Due to the
hardware design of the PC et al, 115 kbps is the maximum bit rate that
can be programmed by software. But by trial and error experimentation,
I found that this UART could be driven at a maximum rate of 38,400 bps.
If I tried to go any faster, I would get garbage or dropped characters.
In this same machine was an expansion board (32-bit microchannel bus)
which contained an extra serial port. It also has a 16550A UART. But I
had no problems driving it at 57,600 bps. Perhaps it would have been
capable of higher speeds than that, but I didn't have a fast enough
device to test it with at the time.
The point is that all serial ports are not created equal. The most
common PC serial ports use 16550A UARTs, but older and slower UARTs
are used in some older boards. Even if the UARTs are the same,
the actual maximum bit rate can be lower than the manufacturer's
specs, depending on what limitations are imposed by the supporting
circuitry.
As to a VT100 emulation vs. a VT102 emulation, that is a software
issue. The serial port doesn't know or care what kind of terminal
you have. Apparently your two servers are not identical, as you
led us to believe.
As to what my next suggestion was going to be, I had some questions about
the procedure you used to comment out the entry in /etc/inittab and
kill getty. You didn't provide much information about it. (Perhaps
you're noticing a theme here.) Normally, init only reads /etc/inittab
during startup. Thus, commenting out the entry for getty in /etc/inittab
will not prevent the process from being re-spawned. However, init will
re-read /etc/inittab if you tell it to by means of the "telinit q"
command. The proper procedure would be
(1) Comment out the entry in /etc/inittab
(2) Issue "telinit q"
(3) Wait a reasonable length of time for init to react
(4) Kill getty, if it is still running
(5) Wait for getty to die
(6) Launch minicom
The reverse procedure would be
(1) Exit minicom
(2) Uncomment the entry in /etc/inittab
(3) Issue "telinit q"
init should then re-spawn a getty process. Keep in mind that telinit and
kill are asynchronous commands. They send a signal to another process,
but they do not wait for the requested action to be performed. You must
introduce some wait time in your script to give the other process enough
time to perform the requested action before going on.
>
> Thanks for you all. Much appreciated.
You're welcome. But next time, please give us the information we ask
for and be willing to try the things we suggest, even if you don't think
that it will do any good. It motivates us to keep helping you.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
Reply to: