From owner-freebsd-sparc64@FreeBSD.ORG Tue May 26 19:17:58 2009 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7E7C10656B2 for ; Tue, 26 May 2009 19:17:58 +0000 (UTC) (envelope-from steve@kcilink.com) Received: from yertle.kcilink.com (thingy.kcilink.com [74.92.149.59]) by mx1.freebsd.org (Postfix) with ESMTP id 82AD78FC13 for ; Tue, 26 May 2009 19:17:58 +0000 (UTC) (envelope-from steve@kcilink.com) Received: from steve.int.kcilink.com (steve.int.kcilink.com [192.168.7.99]) by yertle.kcilink.com (Postfix) with ESMTP id 857728A253; Tue, 26 May 2009 15:17:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kcilink.com; s=kci0709; t=1243365477; bh=QKUCaO8u+ljTOGoKJHZCfuK2BHbt6qVlYp/NEx3/2fY=; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References; b=RQWdCKTs83VGq0mBlFZOgLwgPxY/JonBYaDWk5fSvFA9C0bR377NWDa5fXCE/a07y mUfYlUzrvZIwhVnP3SkshtlWIziq7wubw6Q6Jc+0CVlXIwraXbL1FTZBemWv7Hu6CW jTd5Q9x+8jLFl2q8RpWMSK4w335WfuTsIuBiXIhM= Message-Id: <3EBD0181-3670-4FB1-BC2C-33A74A8B371D@kcilink.com> From: Steve Scally To: freebsd-sparc64@freebsd.org In-Reply-To: <20090521144625.GA89774@alchemy.franken.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 26 May 2009 15:17:57 -0400 References: <43658782-451B-4B3E-9F59-6E04409AFAA1@kcilink.com> <20090519175501.GA65063@alchemy.franken.de> <20090521144625.GA89774@alchemy.franken.de> X-Mailer: Apple Mail (2.935.3) Cc: Marius Strobl Subject: Re: Serial Port Troubleshooting X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 19:17:59 -0000 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) call completed >> (Tue May 19 14:38:21 2009) call terminated >> >> Dell >> >> (Tue May 19 14:35:55 2009) call completed >> (Tue May 19 14:36:34 2009) 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 > "