This is a general problem that I’ve seen a lot of, and it would be really nice if this were finally fixed.
Basically, PC manufacturers have a setting called “Console Redirection”, which duplicates the output on the Video Port onto the serial screen (well, the ASCII chars at least, of course).
This feature is common on the more expensive server-class motherboards. The basic problem is that the Digi Portserver 16 seems to be messing up the output of these characters with its own interpretation of what should be on the screen.
Is there a simple way of working around this?
If one doesn’t use the Digi Portserver 16, and instead uses COM1 on a PC (running Fedora and minicom), the output looks perfect on the terminal.
But if one instead uses minicom over RealPort, the output is garbled. The same applies for direct connections to the Portserver via telnet.
In short, the ROM-BIOS developers send their output expecting a pure serial card. They don’t usually know about (or have access to) a PortServer.
It’s clearly a terminfo/termios problem. I’ve tried all sorts of combinations on the ROM BIOS, RealPort and the minicom settings as to what type of terminal it is. But all without success.
The bottom line is that direct connections work fine. But once the Portserver gets in the way, then the terminal screen gets messed up.
Is there a way to completely turn off the termio settings for the Digi? Say, some magic field in the ditty term command? I would really like the RealPort tty drivers to be as close to a standard serial port as possible.
What OS are you running Realport on, and which version of Realport do you have loaded. The product you mention (Portserver 16) is very old, so I suspect the driver is just as old and updating it might resolve your issue.
I’m current using Fedora Core 5, and am about to try it with CentOS 5. The version of RealPort is from the dgrp-1.9-17.src.rpm
Is there a later version? I was under the impression that this RPM was released last spring? It’s actually a Portserver TS 16, with (I believe) the latest firmware for this particular model on it:
Model: PortServer
Type: TS 16
Firmware version: Version 82000854_J1 06/15/2004
Yes, indeed. The only difference that I noticed was with the ditty specific differences at the top of its output.
I don’t have the output immediately available, so let me re-run this using CentOS 5. I’ve just recently gotten the kernel to compile, and have to go through the installation procedures again.
A couple points of note. First, I have, for a limited time, direct access to one of the BIOS engineers at this motherboard company, and can get any changes done there that are needed for the BIOS.
I also had a second thought. Namely, if any of your internal IT guys are using serial consoles, they might have some ideas. This may be a long shot, as IT setups vary widely. But I thought I’d mention it in case any insight was to be gained there.
I’ll have the results from the CentOS installation later today.
You may find that monitoring the port using dpa.dgrp very helpful here. There is an option to view/capture the actual serial data “M” and many times monitoring the serial signals can give additional clues.
What cabling pinouts are being used to connect the console to the PortServer? Are there specific signal assertions required by the BIOS?
Typically, garbage signifies a baud, parity, character bit, stop bit, or flow control mis-match. Are there possibly settings on the PortServer implemented aside from the “RealPort” profile? When the RealPort profile is used, all other serial settings should remain at the default values (left unchanged).
Oh, thanks! I was unaware of using dpa.dgrp. I’ll give that a try.
The actual cabling is just a cat 5/6 cable connected from the Portserver to the DB9 DTE port on the PC. The specifics are below, and I’ve included the color codes as they might be useful to others. This only has the color codes, but those should be the standard RJ45 codes. I can dig up the specific color-RJ45 pin mappings if you like.
Note that no flow control is set, at 115200 baud. I can look at changing that, but everything works flawlessly after I get to grub and boot the kernel, both using the serial console. Which leads me to suspect the terminfo chars, as this has historically been a pain.
Still, if one is dropping escape sequences, then that would also result in a messed up screen. But at this point, I’m not seeing any dropped chars that I’ve noticed.
I’m going to do a quick test at 9600 baud, as all modern serial chips with a FIFO should support that with no problem (even the old 8250’s could handle that).
Thanks for the quick replies.
Digi TS16 to DTE (PC console):
Female: Looking Towards the Front/Outside:
…5 4 3 2 1
._____________
.\ o o o o o /
…\ o o o o /
…---------
…9 8 7 6
DB9 RJ45-DB9
Pin Connector Colors
1 - X
2 - Red
3 - Green
4 - Brown
5 - Yellow
6 - White
7 - Blue
8 - Orange
9 - X
Thanks. Yes, I do believe these match up, as that was one of the docs that I perused when translating the cable connections.
In my case, the cable diagram refers to the more common little $2 db9-rj45 cable kits that one can easily buy. It has worked flawlessly for me several times.
I’ve finally tracked down a working setup. Here’s what works:
pc-bios: vt100
Portserver TS 16: vt100
(via ditty term vt100 /dev/ttyXXYY)
Minicom: vt102
Baud Rate: 9600
In short, trimming the baud rate down to 9600, as well as using this combination of settings, works just fine. Characters must have been being dropped when at the BIOS level, and not at the grub or kernel level. Plus one has to match the right terminal settings appropriately.
Thank you VERY MUCH for your help here! It is much appreciated.