Serial multiport error Oxford/Startech PEX2S952
freebsd at jdc.parodius.com
Wed Aug 24 12:00:01 UTC 2011
On Wed, Aug 24, 2011 at 12:13:08PM +0100, David Wood wrote:
> Hi Greg,
> In message <20110824070826.GK92605 at core.byshenk.net>, Greg Byshenk
> <freebsd at byshenk.net> writes
> >On Mon, Aug 22, 2011 at 11:59:11AM +0100, David Wood wrote:
> >>In message <20110822094756.GJ92605 at core.byshenk.net>, Greg Byshenk
> >><freebsd at byshenk.net> 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
> >>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
> >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
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 Chadwick jdc 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 |
More information about the freebsd-stable