Date: Tue, 26 May 2009 15:17:57 -0400 From: Steve Scally <steve@kcilink.com> To: freebsd-sparc64@freebsd.org Cc: Marius Strobl <marius@alchemy.franken.de> Subject: Re: Serial Port Troubleshooting Message-ID: <3EBD0181-3670-4FB1-BC2C-33A74A8B371D@kcilink.com> In-Reply-To: <20090521144625.GA89774@alchemy.franken.de> References: <43658782-451B-4B3E-9F59-6E04409AFAA1@kcilink.com> <20090519175501.GA65063@alchemy.franken.de> <DA77FB7D-899E-40D9-A705-323CD09C430E@kcilink.com> <20090521144625.GA89774@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Marius,
My status update.
On May 21, 2009, at 10:46 AM, Marius Strobl wrote:
> 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:
>>>> Hello,
>>>>
>>>> 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
>>>> using
>>>> the serial connection from the Dell box. However now when trying
>>>> to
>>>> connect from the Sun to the Dell I only receive the "connected"
>>>> string
>>>> 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:
> console="comconsole"
> hw.uart.console="io:0x3f8,br:9600"
I setup my Dell machine to use uart instead of sio and I received
the same result that I started with.
The Dell can connect to the Sun machine however, the Sun can not
connect to the Dell.
My kernel config file had
include GENERIC
ident BUZZ-GENERIC
nodevice sio
device uart
device puc
I tried two different builds with and without the puc driver even
though I don't have a pci serial card. I was
just testing all options.
My loader.conf contained the settings you had above. When that
didn't work and after searching online I
found these settings and adjusted them accordingly to match what I
had in my dmesg output.
http://jdc.parodius.com/freebsd/uart.txt
hint.uart.0.at="isa"
hint.uart.0.port="0x3F8"
hint.uart.0.flags="0x10"
hint.uart.0.irq="4"
hint.uart.1.at="isa"
hint.uart.1.port="0x2F8"
hint.uart.1.irq="3"
hint.uart.2.disabled="1"
hint.uart.3.disabled="1"
I also added the information below to my ttys file
# Serial terminals (for uart(4))
ttyu0 "/usr/libexec/getty std.9600" vt100 on secure
ttyu1 "/usr/libexec/getty std.9600" vt100 on secure
ttyu2 "/usr/libexec/getty std.9600" dialup off secure
ttyu3 "/usr/libexec/getty std.9600" dialup off secure
I tried having just ttyu0 listen, ttyu1 and then put both set to
on. I have not tried using minicom yet as it takes a bit to
rebuilt and test kernel config changes. If using minicom doesn't
work I suppose I will revert the Dell box to 6.3 and then upgrade to
7.0, 72.
I will also revert the Sun box to 7.0 then do the test of Sun 7.0
Dell 6.3, Sun 7.0 Dell 7.0, Sun 7.0, Dell 7.2 and see at which point
the serial port stops working. If I go back to a known working
configuration and it still does not work then I know it is most likely a
hardware issue and maybe the port has just stopped working. I
will keep you updated on my findings. Thank you and also to everyone
that
gave me responses.
>
>
>>
>> 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
> case though
>
>>
>> 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.
>>
>> Sun
>>
>> (Tue May 19 14:37:56 2009) <cu9600, , /dev/cuau0> call completed
>> (Tue May 19 14:38:21 2009) <cu9600, , /dev/cuau0> call terminated
>>
>> Dell
>>
>> (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@buzz]% cu -l /dev/cuad1
>> Connected
>>
>> FreeBSD/sparc64 (etch) (ttyu1)
>>
>> login:
>>
>> Connecting Sun to Dell using cu -l /dev/cuau0
>>
>> etch# cu -l /dev/cuau0
>> Connected
>>
>> I appreciate your help and thanks again.
>
> Marius
>
> _______________________________________________
> freebsd-sparc64@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
> To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org
> "
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EBD0181-3670-4FB1-BC2C-33A74A8B371D>