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 : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1859366348.1893779.1301756864696.javamail.r...@md01.wow.synacor.com