Re: Serial multiport error Oxford/Startech PEX2S952
On Aug 24, 2011, at 4:59 AM, Jeremy Chadwick wrote: >> >> It may also be interesting to try 9.x on a machine with a serial >> port that operates directly with uart(4). Does stty(4) throw up >> "isn't a terminal" errors against the .init and .lock devices >> relating to those ports? I would try this myself, but am very short >> of time at present. >> >> >> Though there is probably little more that I can add, please keep me >> cc'd on all relevant e-mails, especially as I do not follow >> freebsd-current. > > I'm CC'ing Marcel Moolenaar here, who's the author of uart(4), to help > assist in this matter and shed some light on the above comments. If > there's a quirk or bug there, I'm certain he'll assist in helping. There's no obvious problem in uart(4). The handling of *.init and *.lock is all unified in the TTY layer. Note that the typical scenario for uart(4) to not respect the baud rate setting is when the UART port is a system device (i.e. serial console or debug port). Make sure there's no difference between 8.x and 9.x with respect to which ports are declared as system ports. FYI, -- Marcel Moolenaar mar...@xcllnt.net ___ 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"
Re: Serial multiport error Oxford/Startech PEX2S952
On Wed, Aug 24, 2011 at 12:13:08PM +0100, David Wood wrote: > Hi Greg, > > In message <20110824070826.gk92...@core.byshenk.net>, Greg Byshenk > writes > >On Mon, Aug 22, 2011 at 11:59:11AM +0100, David Wood wrote: > > > >>In message <20110822094756.gj92...@core.byshenk.net>, Greg Byshenk > >> writes > >>>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. > >> > >>You could try > >>hint.uart.2.baud="115200" > >> > >>in /boot/device.hints - making the relevant changes to port number and > >>speed according to your needs. > > > >This does not help; speed remains set to 9600. > > It was worth a go. > > > >>>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. > >> > >>It will be interesting to see if there is a difference between 8.x and > >>9.x. > > > >Yes, there is. > > > >Using 8-STABLE (with sources from 17 August 2011) and inbuilt puc, > >the controller works as expected. It defaults to 9600, but setting > >the speed on the cuaa?.lock and cuaa?.init devices works. > > > >Interestingly, setting the speed in device.hints does _not_ work. > > It could be that setting speed in /boot/device.hints only works with > ports directly handled by uart(4), not ports that uart(4) handles > via puc(4). > > As 8-STABLE works, the support code I wrote and contributed works > for your card, which is encouraging. > > > >So, it appears that there is something wrong (or at least different) > >with 9.x > > The best course of action is likely to be bringing up this problem > on freebsd-current (as 9.x is not yet -stable) and filing a PR, > noting the regression between 8-STABLE and 9-BETA. > > I'm fairly sure that the problem is likely to be in uart(4) or in > something on which uart(4) rests, such as the tty layer. Even in > 9-BETA puc(4) appears to be doing its job of identifying and > configuring the ports before invoking uart(4) - so puc(4) doesn't > appear to be to blame. > > > >Doing some poking around, I see that, in 9.x, termios.h is not > >included in dev/uart/uart_core.c and dev/uart/uart_tty.c. While > >it is included under 8.x. > > The commit logs for HEAD show that the inclusion of termios headers > was removed as unnecessary (see r199872). I doubt that the problem > is merely a missing header, not least as missing headers normally > result in compilation failure. > > The "isn't a terminal" error you are getting indicates that the > attempt to call tcgetaddr(3) on a file descriptor opened on the > device is failing. Unfortunately, I am not familiar enough with the > tty code to understand why that call is failing on 9.x. > > > If posting on freebsd-current and filing a PR don't produce an > answer, ed@ or kib@ may be able to throw some light. Those two > committers are responsible for most of the relevant code, especially > the tty layer. > > It may also be interesting to try 9.x on a machine with a serial > port that operates directly with uart(4). Does stty(4) throw up > "isn't a terminal" errors against the .init and .lock devices > relating to those ports? I would try this myself, but am very short > of time at present. > > > Though there is probably little more that I can add, please keep me > cc'd on all relevant e-mails, especially as I do not follow > freebsd-current. I'm CC'ing Marcel Moolenaar here, who's the author of uart(4), to help assist in this matter and shed some light on the above comments. If there's a quirk or bug there, I'm certain he'll assist in helping. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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"
Re: Serial multiport error Oxford/Startech PEX2S952
Hi Greg, In message <20110824070826.gk92...@core.byshenk.net>, Greg Byshenk writes On Mon, Aug 22, 2011 at 11:59:11AM +0100, David Wood wrote: In message <20110822094756.gj92...@core.byshenk.net>, Greg Byshenk writes >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. You could try hint.uart.2.baud="115200" in /boot/device.hints - making the relevant changes to port number and speed according to your needs. This does not help; speed remains set to 9600. It was worth a go. >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. It will be interesting to see if there is a difference between 8.x and 9.x. Yes, there is. Using 8-STABLE (with sources from 17 August 2011) and inbuilt puc, the controller works as expected. It defaults to 9600, but setting the speed on the cuaa?.lock and cuaa?.init devices works. Interestingly, setting the speed in device.hints does _not_ work. It could be that setting speed in /boot/device.hints only works with ports directly handled by uart(4), not ports that uart(4) handles via puc(4). As 8-STABLE works, the support code I wrote and contributed works for your card, which is encouraging. So, it appears that there is something wrong (or at least different) with 9.x The best course of action is likely to be bringing up this problem on freebsd-current (as 9.x is not yet -stable) and filing a PR, noting the regression between 8-STABLE and 9-BETA. I'm fairly sure that the problem is likely to be in uart(4) or in something on which uart(4) rests, such as the tty layer. Even in 9-BETA puc(4) appears to be doing its job of identifying and configuring the ports before invoking uart(4) - so puc(4) doesn't appear to be to blame. Doing some poking around, I see that, in 9.x, termios.h is not included in dev/uart/uart_core.c and dev/uart/uart_tty.c. While it is included under 8.x. The commit logs for HEAD show that the inclusion of termios headers was removed as unnecessary (see r199872). I doubt that the problem is merely a missing header, not least as missing headers normally result in compilation failure. The "isn't a terminal" error you are getting indicates that the attempt to call tcgetaddr(3) on a file descriptor opened on the device is failing. Unfortunately, I am not familiar enough with the tty code to understand why that call is failing on 9.x. If posting on freebsd-current and filing a PR don't produce an answer, ed@ or kib@ may be able to throw some light. Those two committers are responsible for most of the relevant code, especially the tty layer. It may also be interesting to try 9.x on a machine with a serial port that operates directly with uart(4). Does stty(4) throw up "isn't a terminal" errors against the .init and .lock devices relating to those ports? I would try this myself, but am very short of time at present. Though there is probably little more that I can add, please keep me cc'd on all relevant e-mails, especially as I do not follow freebsd-current. With best wishes, David -- David Wood da...@wood2.org.uk ___ 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"
Re: Serial multiport error Oxford/Startech PEX2S952
On Mon, Aug 22, 2011 at 11:59:11AM +0100, David Wood wrote: > In message <20110822094756.gj92...@core.byshenk.net>, Greg Byshenk > writes > >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. > > You could try > hint.uart.2.baud="115200" > > in /boot/device.hints - making the relevant changes to port number and > speed according to your needs. This does not help; speed remains set to 9600. > >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. > > It will be interesting to see if there is a difference between 8.x and > 9.x. Yes, there is. Using 8-STABLE (with sources from 17 August 2011) and inbuilt puc, the controller works as expected. It defaults to 9600, but setting the speed on the cuaa?.lock and cuaa?.init devices works. Interestingly, setting the speed in device.hints does _not_ work. So, it appears that there is something wrong (or at least different) with 9.x Doing some poking around, I see that, in 9.x, termios.h is not included in dev/uart/uart_core.c and dev/uart/uart_tty.c. While it is included under 8.x. If I look at the 8.x .c files, they want #include ... which appears to no longer be used. But adding either that, or #include ... produces errors: /usr/src/sys/dev/uart/uart_core.c:47:21: error: termios.h: No such file or directory /usr/src/sys/dev/uart/uart_tty.c:42:21: error: termios.h: No such file or directory mkdep: compile failed *** Error code 1 Though a fresh build of world seems to produce termios.h: # find /usr/obj/ |grep termios.h /usr/obj/usr/src/lib32/usr/include/sys/termios.h /usr/obj/usr/src/lib32/usr/include/sys/_termios.h /usr/obj/usr/src/lib32/usr/include/termios.h /usr/obj/usr/src/tmp/usr/include/termios.h /usr/obj/usr/src/tmp/usr/include/sys/termios.h /usr/obj/usr/src/tmp/usr/include/sys/_termios.h # But I may be completely confused here, as I don't pretend to be familiar with all of the details of the build process. Does this look like a bug with 9.x, or something that should be done differently? -- 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"
Re: Serial multiport error Oxford/Startech PEX2S952
Dear Greg, In message <20110822094756.gj92...@core.byshenk.net>, Greg Byshenk writes 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. You could try hint.uart.2.baud="115200" in /boot/device.hints - making the relevant changes to port number and speed according to your needs. 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. It will be interesting to see if there is a difference between 8.x and 9.x. I'll followup again when I have something to report. I look forward to further feedback. With best wishes, David -- David Wood da...@wood2.org.uk ___ 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"
Re: Serial multiport error Oxford/Startech PEX2S952
On Mon, Aug 22, 2011 at 10:23:14AM +0100, David Wood wrote:
> In message <20110822083336.gi92...@core.byshenk.net>, Greg Byshenk
> writes
> >On Mon, Aug 22, 2011 at 12:20:33AM +0200, Greg Byshenk wrote:
> >>puc0: mem
> >>0xf9dfc000-0xf9df,0xfa00-0xfa1f,0xf9e0-0xf9ff 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=TONEOFF 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=TONEOFF 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
Re: Serial multiport error Oxford/Startech PEX2S952
Hi Greg,
In message <20110822083336.gi92...@core.byshenk.net>, Greg Byshenk
writes
On Mon, Aug 22, 2011 at 12:20:33AM +0200, Greg Byshenk wrote:
puc0: mem
0xf9dfc000-0xf9df,0xfa00-0xfa1f,0xf9e0-0xf9ff 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=TONEOFF 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=TONEOFF 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
da...@wood2.org.uk
___
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"
Re: Serial multiport error Oxford/Startech PEX2S952
On Mon, Aug 22, 2011 at 12:20:33AM +0200, Greg Byshenk wrote:
> On Sun, Aug 21, 2011 at 09:44:41PM +0100, David Wood wrote:
>
> > I wrote and contributed the support code for the OXPCIe95x serial chips
> > - and just happened to notice your report.
>
> Thanks for the response.
>
>
> > In message <20110821154249.ge92...@core.byshenk.net>, Greg Byshenk
> > writes
> > >I'm having a problem with a StarTech PEX2S952 dual-port serial
> > >card.
> > >
> > >I believe that it should be supported, as it has this entry in
> > >pucdata.c
> > >
> > >[...]
> > > { 0x1415, 0xc158, 0x, 0,
> > > "Oxford Semiconductor OXPCIe952 UARTs",
> > > DEFAULT_RCLK * 0x22,
> > > PUC_PORT_NONSTANDARD, 0x10, 0, -1,
> > > .config_function = puc_config_oxford_pcie
> > > },
> > >[...]
> >
> > It should be supported. The OXPCIe952 is more awkward to support than
> > the OXPCIe954 and OXPCIe958 because it can be configured in so many
> > different ways by the board manufacturer. However, 0xc158 is
> > configuration that is identical in arrangement as the larger chips, so
> > is the configuration I'm most confident of. I've just double-checked the
> > data sheets, and can't see any relevant differences between 0xc158
> > OXPCIe952 and the OXPCIe954 I tested the code with.
> >
> > I use my OXPCIe954 board on FreeBSD 8.2, and have had success reports
> > from other OXPCIe954 and OXPCIe958 board users (including someone with a
> > 16 port board based on dual OXPCIe958s). I have yet to try FreeBSD 9.x
> > on my hardware.
> >
> >
> > >And, while it is recognized at boot -- after adding
> > >
> > > device puc
> > > options COM_MULTIPORT
> >
> > I'm 99% certain that "options COM_MULTIPORT" relates to the old sio(4)
> > code - I certainly don't need it on 8.x. Does it make any difference if
> > you delete that line and just leave "device puc"?
>
> I will rebuild my kernel and try.
>
>
> > >to my kernel, it doesn't seem to be working. The devices '/dev/cuau2'
> > >and '/dev/cuau3' show up, and I can connect to them, but they don't
> > >seem to pass any traffic. If I connect to the serial console of
> > >another machine (one that I know for certain is working), I get
> > >nothing at all.
> >
> > Have you remembered to set the speed (and other relevant options) on the
> > .init devices? This is a feature (or is it a quirk) of the uart(4)
> > driver that catches many people out. Setting options on the base device
> > is normally a no-op.
> >
> > For example, if the remote device on /dev/cuau2 operates at 115200 bps
> > with hardware handshaking, try:
> >
> > stty -f /dev/cuau2.init speed 115200 crtscts
>
> Interestingly, it -is- a no-op on the device, which I hadn't noticed.
> But trying to set it on the .init fails:
>
> # stty -f /dev/cuau2.init speed 115200
> stty: /dev/cuau2.init isn't a terminal crtscts
> #
>
>
> > One frustrating aspect of adding puc(4) support for many devices is that
> > you can't be certain of the clock rate multiplier - the same device can
> > crop up on a different manufacturer's board with a different multiplier.
> > This problem doesn't occur with the OXPCIe95x devices as they derive
> > their 62.5MHz UART clock from the PCI Express clock. Consequently, the
> > problem can't be that your board inadvertently operating the UARTs at
> > the wrong speed.
> >
> >
> > >I suspect (?) that it may not be recognized as the proper card. Boot
> > >and pciconf messages are:
> > >
> > >puc0: mem
> > >0xf9dfc000-0xf9df,0xfa00-0xfa1f,0xf9e0-0xf9ff irq
> > >30 at device 0.0 on pci4
> >
> > That is correct. Are there any more lines afterwards - especially one
> > giving the number of UARTs detected? That line is crucial, as, on these
> > chips, the number of UARTs has to be read from configuration space
> > because you can slave two chips together.
> >
> > My OXPCIe954 board is recognised thus (FreeBSD 8.2 amd64):
> >
> > puc0: mem
> > 0xd5efc000-0xd5ef,0xd5c0-0xd5df,0xd5a0-0xd5bf irq 18
> > at device 0.0 on pci8
> > puc0: 4 UARTs detected
> > puc0: [FILTER]
> > uart2: <16950 or compatible> on puc0
> > uart2: [FILTER]
> > uart3: <16950 or compatible> on puc0
> > uart3: [FILTER]
> > uart4: <16950 or compatible> on puc0
> > uart4: [FILTER]
> > uart5: <16950 or compatible> on puc0
> > uart5: [FILTER]
>
> puc0: mem
> 0xf9dfc000-0xf9df,0xfa00-0xfa1f,0xf9e0-0xf9ff 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
>
>
> > >puc0@pci0:4:0:0:class=0x070002 card=0xc1581415 chip=0xc1581415
> > >rev=0x00 hdr=0x00
> > > vendor = 'Oxford Semiconductor Ltd'
> > > class = simple comms
> > > subclass = UART
> > > bar [10] = type Memory, range 32, base 0xf9dfc000, size 16384, enabled
> > > bar [14]
Re: Serial multiport error Oxford/Startech PEX2S952
On Sun, Aug 21, 2011 at 09:44:41PM +0100, David Wood wrote:
> I wrote and contributed the support code for the OXPCIe95x serial chips
> - and just happened to notice your report.
Thanks for the response.
> In message <20110821154249.ge92...@core.byshenk.net>, Greg Byshenk
> writes
> >I'm having a problem with a StarTech PEX2S952 dual-port serial
> >card.
> >
> >I believe that it should be supported, as it has this entry in
> >pucdata.c
> >
> >[...]
> > { 0x1415, 0xc158, 0x, 0,
> > "Oxford Semiconductor OXPCIe952 UARTs",
> > DEFAULT_RCLK * 0x22,
> > PUC_PORT_NONSTANDARD, 0x10, 0, -1,
> > .config_function = puc_config_oxford_pcie
> > },
> >[...]
>
> It should be supported. The OXPCIe952 is more awkward to support than
> the OXPCIe954 and OXPCIe958 because it can be configured in so many
> different ways by the board manufacturer. However, 0xc158 is
> configuration that is identical in arrangement as the larger chips, so
> is the configuration I'm most confident of. I've just double-checked the
> data sheets, and can't see any relevant differences between 0xc158
> OXPCIe952 and the OXPCIe954 I tested the code with.
>
> I use my OXPCIe954 board on FreeBSD 8.2, and have had success reports
> from other OXPCIe954 and OXPCIe958 board users (including someone with a
> 16 port board based on dual OXPCIe958s). I have yet to try FreeBSD 9.x
> on my hardware.
>
>
> >And, while it is recognized at boot -- after adding
> >
> > device puc
> > options COM_MULTIPORT
>
> I'm 99% certain that "options COM_MULTIPORT" relates to the old sio(4)
> code - I certainly don't need it on 8.x. Does it make any difference if
> you delete that line and just leave "device puc"?
I will rebuild my kernel and try.
> >to my kernel, it doesn't seem to be working. The devices '/dev/cuau2'
> >and '/dev/cuau3' show up, and I can connect to them, but they don't
> >seem to pass any traffic. If I connect to the serial console of
> >another machine (one that I know for certain is working), I get
> >nothing at all.
>
> Have you remembered to set the speed (and other relevant options) on the
> .init devices? This is a feature (or is it a quirk) of the uart(4)
> driver that catches many people out. Setting options on the base device
> is normally a no-op.
>
> For example, if the remote device on /dev/cuau2 operates at 115200 bps
> with hardware handshaking, try:
>
> stty -f /dev/cuau2.init speed 115200 crtscts
Interestingly, it -is- a no-op on the device, which I hadn't noticed.
But trying to set it on the .init fails:
# stty -f /dev/cuau2.init speed 115200
stty: /dev/cuau2.init isn't a terminal crtscts
#
> One frustrating aspect of adding puc(4) support for many devices is that
> you can't be certain of the clock rate multiplier - the same device can
> crop up on a different manufacturer's board with a different multiplier.
> This problem doesn't occur with the OXPCIe95x devices as they derive
> their 62.5MHz UART clock from the PCI Express clock. Consequently, the
> problem can't be that your board inadvertently operating the UARTs at
> the wrong speed.
>
>
> >I suspect (?) that it may not be recognized as the proper card. Boot
> >and pciconf messages are:
> >
> >puc0: mem
> >0xf9dfc000-0xf9df,0xfa00-0xfa1f,0xf9e0-0xf9ff irq
> >30 at device 0.0 on pci4
>
> That is correct. Are there any more lines afterwards - especially one
> giving the number of UARTs detected? That line is crucial, as, on these
> chips, the number of UARTs has to be read from configuration space
> because you can slave two chips together.
>
> My OXPCIe954 board is recognised thus (FreeBSD 8.2 amd64):
>
> puc0: mem
> 0xd5efc000-0xd5ef,0xd5c0-0xd5df,0xd5a0-0xd5bf irq 18
> at device 0.0 on pci8
> puc0: 4 UARTs detected
> puc0: [FILTER]
> uart2: <16950 or compatible> on puc0
> uart2: [FILTER]
> uart3: <16950 or compatible> on puc0
> uart3: [FILTER]
> uart4: <16950 or compatible> on puc0
> uart4: [FILTER]
> uart5: <16950 or compatible> on puc0
> uart5: [FILTER]
puc0: mem
0xf9dfc000-0xf9df,0xfa00-0xfa1f,0xf9e0-0xf9ff 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
> >puc0@pci0:4:0:0:class=0x070002 card=0xc1581415 chip=0xc1581415
> >rev=0x00 hdr=0x00
> > vendor = 'Oxford Semiconductor Ltd'
> > class = simple comms
> > subclass = UART
> > bar [10] = type Memory, range 32, base 0xf9dfc000, size 16384, enabled
> > bar [14] = type Memory, range 32, base 0xfa00, size 2097152,
> > enabled
> > bar [18] = type Memory, range 32, base 0xf9e0, size 2097152,
> > enabled
>
> That is correct.
>
> >The kernel is actually FreeBSD 9.0-BETA1 amd64, which is not quite
> >'STABLE' yet, but I don't think that this should matt
Re: Serial multiport error Oxford/Startech PEX2S952
Hi Greg,
I wrote and contributed the support code for the OXPCIe95x serial chips
- and just happened to notice your report.
In message <20110821154249.ge92...@core.byshenk.net>, Greg Byshenk
writes
I'm having a problem with a StarTech PEX2S952 dual-port serial
card.
I believe that it should be supported, as it has this entry in
pucdata.c
[...]
{ 0x1415, 0xc158, 0x, 0,
"Oxford Semiconductor OXPCIe952 UARTs",
DEFAULT_RCLK * 0x22,
PUC_PORT_NONSTANDARD, 0x10, 0, -1,
.config_function = puc_config_oxford_pcie
},
[...]
It should be supported. The OXPCIe952 is more awkward to support than
the OXPCIe954 and OXPCIe958 because it can be configured in so many
different ways by the board manufacturer. However, 0xc158 is
configuration that is identical in arrangement as the larger chips, so
is the configuration I'm most confident of. I've just double-checked the
data sheets, and can't see any relevant differences between 0xc158
OXPCIe952 and the OXPCIe954 I tested the code with.
I use my OXPCIe954 board on FreeBSD 8.2, and have had success reports
from other OXPCIe954 and OXPCIe958 board users (including someone with a
16 port board based on dual OXPCIe958s). I have yet to try FreeBSD 9.x
on my hardware.
And, while it is recognized at boot -- after adding
device puc
options COM_MULTIPORT
I'm 99% certain that "options COM_MULTIPORT" relates to the old sio(4)
code - I certainly don't need it on 8.x. Does it make any difference if
you delete that line and just leave "device puc"?
to my kernel, it doesn't seem to be working. The devices '/dev/cuau2'
and '/dev/cuau3' show up, and I can connect to them, but they don't
seem to pass any traffic. If I connect to the serial console of
another machine (one that I know for certain is working), I get
nothing at all.
Have you remembered to set the speed (and other relevant options) on the
.init devices? This is a feature (or is it a quirk) of the uart(4)
driver that catches many people out. Setting options on the base device
is normally a no-op.
For example, if the remote device on /dev/cuau2 operates at 115200 bps
with hardware handshaking, try:
stty -f /dev/cuau2.init speed 115200 crtscts
One frustrating aspect of adding puc(4) support for many devices is that
you can't be certain of the clock rate multiplier - the same device can
crop up on a different manufacturer's board with a different multiplier.
This problem doesn't occur with the OXPCIe95x devices as they derive
their 62.5MHz UART clock from the PCI Express clock. Consequently, the
problem can't be that your board inadvertently operating the UARTs at
the wrong speed.
I suspect (?) that it may not be recognized as the proper card. Boot
and pciconf messages are:
puc0: mem
0xf9dfc000-0xf9df,0xfa00-0xfa1f,0xf9e0-0xf9ff irq
30 at device 0.0 on pci4
That is correct. Are there any more lines afterwards - especially one
giving the number of UARTs detected? That line is crucial, as, on these
chips, the number of UARTs has to be read from configuration space
because you can slave two chips together.
My OXPCIe954 board is recognised thus (FreeBSD 8.2 amd64):
puc0: mem
0xd5efc000-0xd5ef,0xd5c0-0xd5df,0xd5a0-0xd5bf irq 18
at device 0.0 on pci8
puc0: 4 UARTs detected
puc0: [FILTER]
uart2: <16950 or compatible> on puc0
uart2: [FILTER]
uart3: <16950 or compatible> on puc0
uart3: [FILTER]
uart4: <16950 or compatible> on puc0
uart4: [FILTER]
uart5: <16950 or compatible> on puc0
uart5: [FILTER]
puc0@pci0:4:0:0:class=0x070002 card=0xc1581415 chip=0xc1581415
rev=0x00 hdr=0x00
vendor = 'Oxford Semiconductor Ltd'
class = simple comms
subclass = UART
bar [10] = type Memory, range 32, base 0xf9dfc000, size 16384, enabled
bar [14] = type Memory, range 32, base 0xfa00, size 2097152, enabled
bar [18] = type Memory, range 32, base 0xf9e0, size 2097152, enabled
That is correct.
The kernel is actually FreeBSD 9.0-BETA1 amd64, which is not quite
'STABLE' yet, but I don't think that this should matter.
Any advice would be much appreciated. The machine is still in
test phase, so I can mess around with it as necessary.
Hopefully this gets your Startech board working. I look forward to your
feedback.
If all else fails, the board I'm using is Lindy 51189. It's a OXPCIe954
board, offering four ports via a breakout cable, and is normally pretty
cheap direct from lindy.com (quite possibly cheaper than your two port
Startech board!). However, this recommendation comes with the proviso
that I haven't yet tried it with FreeBSD 9.x.
With best wishes,
David
--
David Wood
da...@wood2.org.uk
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsub
Serial multiport error Oxford/Startech PEX2S952
Not sure if -stable is the right place for this, but I'll give it
a shot; if it's not, then a pointer in the right direction would
be much appreciated.
I'm having a problem with a StarTech PEX2S952 dual-port serial
card.
I believe that it should be supported, as it has this entry in
pucdata.c
[...]
{ 0x1415, 0xc158, 0x, 0,
"Oxford Semiconductor OXPCIe952 UARTs",
DEFAULT_RCLK * 0x22,
PUC_PORT_NONSTANDARD, 0x10, 0, -1,
.config_function = puc_config_oxford_pcie
},
[...]
And, while it is recognized at boot -- after adding
device puc
options COM_MULTIPORT
to my kernel, it doesn't seem to be working. The devices '/dev/cuau2'
and '/dev/cuau3' show up, and I can connect to them, but they don't
seem to pass any traffic. If I connect to the serial console of
another machine (one that I know for certain is working), I get
nothing at all.
I suspect (?) that it may not be recognized as the proper card. Boot
and pciconf messages are:
puc0: mem
0xf9dfc000-0xf9df,0xfa00-0xfa1f,0xf9e0-0xf9ff irq 30 at
device 0.0 on pci4
puc0@pci0:4:0:0:class=0x070002 card=0xc1581415 chip=0xc1581415 rev=0x00
hdr=0x00
vendor = 'Oxford Semiconductor Ltd'
class = simple comms
subclass = UART
bar [10] = type Memory, range 32, base 0xf9dfc000, size 16384, enabled
bar [14] = type Memory, range 32, base 0xfa00, size 2097152, enabled
bar [18] = type Memory, range 32, base 0xf9e0, size 2097152, enabled
The kernel is actually FreeBSD 9.0-BETA1 amd64, which is not quite
'STABLE' yet, but I don't think that this should matter.
Any advice would be much appreciated. The machine is still in
test phase, so I can mess around with it as necessary.
Thanks.
--
greg byshenk - free...@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"
