[CentOS] Need to test serial port connection

Thu Feb 26 18:55:22 UTC 2009
William L. Maltby <CentOS4Bill at triad.rr.com>

On Thu, 2009-02-26 at 16:55 +0000, Anne Wilson wrote:
> On Thursday 26 February 2009 13:37, William L. Maltby wrote:
> <snip>

> > > Feb 26 12:12:25 borg2 kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is
> > > a 16550A
> > > Feb 26 12:12:25 borg2 kernel: serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is
> > > a 16550A
> >
> > Didn't you say there was only one port? There might be a second on the
> > main board that is accessible via a header. If it's not hooked up
> > disable all but the first in the BIOS (later). It's not really hurting
> > anything as is, but it will free the I/O address and IRQ for assignment
> > to other devices. 
> 
> I believe you are right. I remember those - and the 25-9-pin adapter :-).  
> Peering around the back in a dark corner, I  could well have been mistaken.  
> OK - female socket, so that's a  COM port, I think.

To be politically correct and eliminate ambiguity, we'll change the
terms here. Socket (formerly female connector) on the computer s/b a
parallel printer port. Almost always a 25 pin in the past, but I've not
kept up with that stuff over the years.

Plug (formerly male connector) on the computer s/b serial ports.

On the cable, this is reversed, of course. Now if the cable has RS-232
on both ends and is not a fully symmetrical null modem cable, it will
make a difference which end is connected to what. Make sure your cable
socket end is what's hooked to the computer. Often the cables will be
labeled which end goes to computer or device.

Sometimes cables have the same gender on both ends. If they've done that
you could just have the cable reversed (presuming it's one of the
asymmetric cables). It's not uncommon for a null to be made by jumpering
certain pins on just one side of the cable and crossing 2 and 3 end to
end.

> 
> Now I'm really confused.  The BIOS definitely only shows one COM port.  To be

Ouch! Since I've not kept up with this stuff I can't sat if there are
other new devices which use 16550 serial drivers. _But_, there are
definitely 2 ports as the detection routines must write to the ports and
read status to determine if it's a 16450, 16550 and revision A or not
(the original 16550 had insufficient buffer IIRC and the A had to be
issued to prevent overflow at higher speeds. CPUs "back in the day" were
just to slow to handle the interrupts quickly enough).

My guess is that your BIOS has a "menu" in the legacy devices area that
has a drop-down or scrollable menu to select which port to configure. In
there you can enable/disable, change default I/O and IRQ settings, etc.
I think you'll find a second port defined.

Which raises the possibility of the computer's connector being on ttyS1
instead of 0. But I suspect if you check the back of the computer you
might see two plug connectors. These should be the serial ports. In
today's world, probably 9 pin.

>  
> honest, I can't remember whether I connected it or not.  I guess I ought to 
> open the box and see what's what, but not today - it's already too late to do 
> that.

Where's your dedication?! Where's your glass of wine?! Not at the same
location?! Time to leave I guess!  :-)

> 
> > But wait until you have things working - I suspect you 
> > have _two_ ports (probably 1 9 pin and 1 25 pin). A second port of 25
> > pins might easily be mistaken for a printer port. Long ago a switch from
> > Centronics style to RS-232 style began to become the "standard".
> > Physically, it looks the same as a serial port, the visual difference
> > being the "gender" of the connector will be opposite.
> >
> > > Feb 26 12:12:25 borg2 kernel: 00:05: ttyS0 at I/O 0x3f8 (irq = 4) is a
> > > 16550A
> > >
> > > Is this what I'm looking for?  I don't see anything else.
> >
> > Yes. That means that all is as expected (i.e. as _I_ expect).
> >
> > > > Also, Minicom is _easy_ to use and understand. Give it a try. Even the
> > > > man pages are not difficult.
> > >
> > > Easy when you know how, eh? :-)  I did try it.  I changed it to
> > > monitor /dev/ttyS0.  Apart from that, I hadn't a clue what to do.  I did
> > > look at the man page, too, but not knowing what I was looking for didn't
> > > help.
> >
> > I haven't used it for a _long_ time, but IIRC there is an interactive
> > menu system that works with some keystroke, maybe <ESC> key. 
> 
> Ctrl-A Z  - yes, I found that.

In one of the menus from there, IIRC, you can set baud rate, parity,
flow control, etc. BTW, someone mentioned UPS. Really dumb ones don't
send anything except a power loss or battery low indication. Old ones
used to do this just be controlling DTR (IIRC) and you couldn't "see"
anything until it was raised. I don't know the details of yours (if it
is a UPS) but there should be some docs or a CD that describes a minimal
amount of that information. Or maybe they expect WinBlows and just put
that information in a help menu.

BTW, someone mentioned RS-232C. That's the cable and electrical
specifications. RS-232D is the connector specifications for a "D" shell
connector. They don _not_ conflict. They are just different parts of the
same overall specification. So you need have no confusion if you see us
reference the seemingly conflicting specifications.

> 
> > Look for 
> > that stuff in the man pages and it should be clear sailing.
> >
> > First, have you set the baud rate correctly? A lot of things used to
> > default to 9600, but 38400 became common later on. Do the docs for the
> > unit specify? If so, use the stty command, or in minicom or other
> > terminal emulator it's method, to set the baud rate to that needed.
> > Usually these days, no parity check is done so 8 bit characters should
> > be OK.
> >
> > Now, since the port is recognized the failure has to be from the port
> > onward. If the RS-232 9 or 25 pin shell is connected via a cable to the
> > main board, make sure that the cable connector is connected to the right
> > header on the main board. Since Linux reported two ports, there should
> > be two headers on the main board (_if_ that's the method - some ma
> > inboards have them mounted directly on the main board). If the
> > header/connector is not keyed, it may be connected backwards. If you
> > have two RS-232D shells (9 or 25 pin) you may be connecting your cable
> > to the wrong one.
> >
> I'll check all that out tomorrow.  I only have a supplied cable for 9 pin, so 
> if everything else checks out I'll just have to try changing settings to 
> ttyS1 and see if that helps.
> 
> > Moving on, have you been able to verify the cable is good? If you have
> > an RS-232 patch device with LED's, you can see activity (DTR, DCD, etc.)
> > by hooking the cable to it. If you don't have one of those, a digital
> > multi-meter can be used to see if you have expected voltages on certain
> > pins (+/- 12 volts, IIRC). If you don't have one of those, a plain old
> > dumb terminal can be hooked up and settings changed in a trial and error
> > method.
> >
> I'm not handy with a multimeter, but if I have to, I'll give it a try :-)
> 
> > Since they supplied the cable, is it new enough to assume that it is not
> > damaged? If so, I suspect something easy like baud rate.
> 
> Brand new.  I know anything's possible, but I'd put a bad cable very low on 
> the list of likelihoods.
> 
> Settings at present:
> 
> A	Serial Device 			: /dev/ttyS0
> B	Lockfile Location		: /var/lock
> C	Callin Program			: 
> D	Callout Program		:
> E	Bps/Par/Bits			: 38400 8N1
> F	Hardware Flow Control	: Yes
> G	Software Flow Control	: No

Hardware flow control is suspect _if_ the device doesn't allow flow
until some event is seen, e.g. DTR or DCD and/or some information from
the device is ready to be transmitted. This could make it look like
nothing is working. But that really depends on how the device is
supposed to behave.

Unless the device can send large amounts of data or requires flow
control, you might try disabling it.

> 
> All this is as set up in nut.  Liebert do supply 'Multilink' software, but in 
> theory nut installs the latest Liebert Multilink drivers.  I'm seriously 
> wondering whether I should remove nut and install the supplied software.  
> However, I realise that I need to check the hardware situation first.  
> Hopefully that will be done tomorrow.
> 
> Anne
> <snip sig stuff>

HTH
-- 
Bill