From owner-freebsd-stable@FreeBSD.ORG Mon Aug 22 09:46:08 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74DB0106566C for ; Mon, 22 Aug 2011 09:46:08 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (core.byshenk.net [62.58.73.230]) by mx1.freebsd.org (Postfix) with ESMTP id C8EFB8FC0C for ; Mon, 22 Aug 2011 09:46:07 +0000 (UTC) Received: from core.byshenk.net (localhost [127.0.0.1]) by core.byshenk.net (8.14.4/8.14.4) with ESMTP id p7M9lvQc058458; Mon, 22 Aug 2011 11:47:57 +0200 (CEST) (envelope-from byshenknet@core.byshenk.net) Received: (from byshenknet@localhost) by core.byshenk.net (8.14.4/8.14.4/Submit) id p7M9lv5i058457; Mon, 22 Aug 2011 11:47:57 +0200 (CEST) (envelope-from byshenknet) Date: Mon, 22 Aug 2011 11:47:56 +0200 From: Greg Byshenk To: David Wood Message-ID: <20110822094756.GJ92605@core.byshenk.net> References: <20110821154249.GE92605@core.byshenk.net> <20110821222033.GH92605@core.byshenk.net> <20110822083336.GI92605@core.byshenk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on core.byshenk.net Cc: freebsd-stable@freebsd.org Subject: Re: Serial multiport error Oxford/Startech PEX2S952 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 09:46:08 -0000 On Mon, Aug 22, 2011 at 10:23:14AM +0100, David Wood wrote: > In message <20110822083336.GI92605@core.byshenk.net>, Greg Byshenk > writes > >On Mon, Aug 22, 2011 at 12:20:33AM +0200, Greg Byshenk wrote: > >>puc0: mem > >>0xf9dfc000-0xf9dfffff,0xfa000000-0xfa1fffff,0xf9e00000-0xf9ffffff irq > >>30 at device 0.0 on pci4 > >>puc0: 2 UARTs detected > >>uart2: <16950 or compatible> at port 1 on puc0 > >>uart3: <16950 or compatible> at port 2 on puc0 > > This indicates that the puc(4) code is working correctly - it recognises > the board, reads via one of the BARs to confirm there are two UARTs, > initialises both UARTs to 16950 mode, then hands off these ports to > uart(4). > > >>I'll follow up tomorrow. Thanks. > > > >Following up: > > > >It appears that indeed, the "options COM_MULTIPORT" is unnecessary > >for 9-BETA; I've rebuilt the kernel without it, and the card is > >still recognized, along with the ports. > > That's what I expected. The only line needed is "device puc". I have no > idea why this can't be included in GENERIC, especially as puc(4) doesn't > work as a module (no drivers are attached to the ports on the puc > board). > > > >But all it not as it should be. I still can't set the speed on the > >card. > > > >> # stty -f /dev/cuau2.init speed 115200 crtscts > >> stty: /dev/cuau2.init isn't a terminal > >> # > > > >And setting speed on the device itself remains a no-op: > > > > # stty -f /dev/cuau2 speed 115200 crtscts > > 9600 > > # > > > >That said, the card -does- seem to work, at least at some level. > >With the speed issue pointed out, I set the connection on the > >other end to 9600, and then it works. But I'd really like it to > >be faster than that (it's just a serial console, so we could > >probably live with 9600, though we wouldn't like it). > > > >If there is reason to think that this could be a 9.x issue, > >then I could try going to 8.x. > > My earlier instructions omitted mention of the lock, which is really > needed if you want to force a particular speed > > > On 8.2: > > [root@manganese ~]# PORT='/dev/cuau5' ; OPTIONS='speed 115200 crtscts' ; > stty -f ${PORT}.lock 0 ; stty -f ${PORT}.init ${OPTIONS} > /dev/null ; > stty -f ${PORT}.lock 1 ; stty -f ${PORT} > speed 115200 baud; > lflags: echoe echoke echoctl > oflags: tab0 > cflags: cs8 -parenb crtscts > [root@manganese ~]# cu -l cuau5 > Connected > ATI4 > U.S. Robotics 56K FAX EXT Settings... > > B0 E1 F1 L2 M1 Q0 V1 X4 Y1 > SPEED=115200 PARITY=N WORDLEN=8 > DIAL=TONE OFF LINE CID=1 > > &A3 &B1 &C1 &D2 &H2 &I2 &K1 > &M4 &N0 &R1 &S0 &T5 &U0 &Y1 > > S00=000 S01=000 S02=043 S03=013 S04=010 S05=008 S06=004 > S07=060 S08=002 S09=006 S10=014 S11=072 S12=050 S13=000 > S15=000 S16=000 S18=000 S19=000 S21=010 S22=017 S23=019 > S25=005 S27=001 S28=008 S29=020 S30=000 S31=128 S32=002 > S33=000 S34=000 S35=000 S36=014 S38=000 S39=012 S40=000 > S41=004 S42=000 > > LAST DIALLED #: > > OK > ~ > [EOT] > [root@manganese ~]# PORT='/dev/cuau5' ; OPTIONS='speed 38400 crtscts' ; > stty -f ${PORT}.lock 0 ; stty -f ${PORT}.init ${OPTIONS} > /dev/null ; > stty -f ${PORT}.lock 1 ; stty -f ${PORT} > speed 38400 baud; > lflags: echoe echoke echoctl > oflags: tab0 > cflags: cs8 -parenb crtscts > [root@manganese ~]# cu -l cuau5 > Connected > ATI4 > U.S. Robotics 56K FAX EXT Settings... > > B0 E1 F1 L2 M1 Q0 V1 X4 Y1 > SPEED=38400 PARITY=N WORDLEN=8 > DIAL=TONE OFF LINE CID=1 > > &A3 &B1 &C1 &D2 &H2 &I2 &K1 > &M4 &N0 &R1 &S0 &T5 &U0 &Y1 > > S00=000 S01=000 S02=043 S03=013 S04=010 S05=008 S06=004 > S07=060 S08=002 S09=006 S10=014 S11=072 S12=050 S13=000 > S15=000 S16=000 S18=000 S19=000 S21=010 S22=017 S23=019 > S25=005 S27=001 S28=008 S29=020 S30=000 S31=128 S32=002 > S33=000 S34=000 S35=000 S36=014 S38=000 S39=012 S40=000 > S41=004 S42=000 > > LAST DIALLED #: > > OK > ~ > [EOT] > > > This is one of my OXPCIe954 ports - the modem on that port identifies > the speed it is being talked to in the ATI4 output. > > If this is a 9.x issue, it seems more likely to be in the uart(4) code - > though I haven't been following development. If you are getting nowhere > with 9.x, can you try with 8.x? stable/8 might be the best choice, as > the necessary pucdata.c changes postdates 8.2-RELEASE. That said, I > patch 8.2-RELEASE on my machine, choosing to keep things conservative. > > I look forward to your feedback. It doesn't seem to matter; both cuau?.lock and cuau?.init produce the error (for both ports), and cuau? itself remains a no-op. Now that I can see that the card is working (at least minimally), it begins to look as if there might be a problem somewhere in 9.x. I'll try to install 8.x and see if the results are different. I'll followup again when I have something to report. -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL