On Mon, Aug 22, 2011 at 10:23:14AM +0100, David Wood wrote:
> In message <20110822083336.gi92...@core.byshenk.net>, Greg Byshenk
> <free...@byshenk.net> writes
> >On Mon, Aug 22, 2011 at 12:20:33AM +0200, Greg Byshenk wrote:
> >>puc0: <Oxford Semiconductor OXPCIe952 UARTs> 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 - gbysh...@byshenk.net - Leiden, NL
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
