Serial Port Troubleshooting
marius at alchemy.franken.de
Thu May 21 14:46:28 UTC 2009
On Tue, May 19, 2009 at 02:44:29PM -0400, Steve Scally wrote:
> Marius & all,
> First thank you for your responses.
> On May 19, 2009, at 1:55 PM, Marius Strobl wrote:
> >On Mon, May 18, 2009 at 11:49:14AM -0400, Steve Scally wrote:
> >>I currently have two machines one Ultra60 and one Dell GX400. Both
> >>of these boxes have two serial ports. Currently port A on the Sun
> >>goes to com2 on the Dell and com1 on the Dell goes to port B on the
> >>Sun. I upgraded my Ultra60 to FreeBSD 7.2 from 7.0 last night
> >>the serial connection from the Dell box. However now when trying to
> >>connect from the Sun to the Dell I only receive the "connected"
> >>and no prompt. I also tried connecting to the Dell from the Sun and
> >>then rebooting the dell from another terminal. When the Dell box
> >>reaches the multi-user prompt the terminal window with the serial
> >>connection receives a question mark, "?."
> >Does this imply that the low-level console works, i.e. you get
> >the dmesg output of the kernel etc. but at the point getty(8)
> >should take over things break?
> >Does the other way work, i.e. can you login in to the Sun from
> >the Dell machine?
> >What happens if you connect each machine to itself and try to
> >log in?
> >Have you tried with something different than cu(1), f.e.
> >minicom from ports?
> To answer your questions. I assume the low-level console is working
> if it is showing up the dmesg output. Is there any other way to
> verify this?
If you get the kernel output this should be a sufficient proof
that the low-level console on the Dell machine, the cabling and
the terminal emulation on the Sun machine are all working. If
the TTY also duplicates as console device like in your case a
3-wire cabling is actually sufficient, otherwise it would also
need to deliver a DCD.
You could additionally test whether the low-level console input
actually also works. The only way to do so that I currently can
think of is to build a kernel with ddb(4) and check whether its
prompt works. I don't think you'll gain any information related
to your problem by doing so though.
> I appears that yes at this point the failure is occurring when getty
> should be taking over, is there way to verify this as well?
Unfortunately I can't think of one. Unless you want to delve
into debugging the code the only thing I can suggest is to
try to use uart(4) instead of sio(4) as the problem seems to
be on the side of the Dell machine as its low-level console
works. Note that besides needing to use ttyu0 instead of ttyd0
in /etc/ttys and a kernel without sio(4), setting up uart(4)
as a console also differs from sio(4) on amd64 and i386, i.e.
you don't need a boot.config but instead should put something
like the following in /boot/loader.conf:
> I can indeed login to the Sun from the Dell using tip and cu, I have
> not tried minicom simply because cu worked before.
Well, cu(1) and tip(1) often don't work for me (i.e. no
communication) while things like conserver and minicom just
do, so I prefer to use the latter even if they are overkill
for my needs. This doesn't seem to be the problem in your
> I will try tonight to remove all serial cables, reboot both boxes
> without any serial cables attached, then I will just attach the Sun to
> Dell setup and try again.
> This is the only output I have from /var/log/aculog.
> (Tue May 19 14:37:56 2009) <cu9600, , /dev/cuau0> call completed
> (Tue May 19 14:38:21 2009) <cu9600, , /dev/cuau0> call terminated
> (Tue May 19 14:35:55 2009) <cu9600, , /dev/cuad1> call completed
> (Tue May 19 14:36:34 2009) <cu9600, , /dev/cuad1> call completed
> Connecting Dell to Sun using cu -l /dev/cuad1
> [root at buzz]% cu -l /dev/cuad1
> FreeBSD/sparc64 (etch) (ttyu1)
> Connecting Sun to Dell using cu -l /dev/cuau0
> etch# cu -l /dev/cuau0
> I appreciate your help and thanks again.
More information about the freebsd-sparc64