Hi Greg,
In message <20110824070826.gk92...@core.byshenk.net>, Greg Byshenk
<free...@byshenk.net> writes
On Mon, Aug 22, 2011 at 11:59:11AM +0100, David Wood wrote:
In message <20110822094756.gj92...@core.byshenk.net>, Greg Byshenk
<free...@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
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"
