Serial multiport error Oxford/Startech PEX2S952

[David Wood]

Hi Greg,

In message <20110822083336.GI92605 at core.byshenk.net>, Greg Byshenk 
<freebsd at 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 at 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 at 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 at 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 at 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.


With best wishes,



David
-- 
David Wood
david at wood2.org.uk