Date: Wed, 24 Aug 2011 12:13:08 +0100 From: David Wood <david@wood2.org.uk> To: Greg Byshenk <freebsd@byshenk.net> Cc: freebsd-stable@freebsd.org Subject: Re: Serial multiport error Oxford/Startech PEX2S952 Message-ID: <tDjrcvEEzNVOFAuY@wood2.org.uk> In-Reply-To: <20110824070826.GK92605@core.byshenk.net> References: <20110821154249.GE92605@core.byshenk.net> <kI9Z%2BkE54WUOFA36@wood2.org.uk> <20110821222033.GH92605@core.byshenk.net> <20110822083336.GI92605@core.byshenk.net> <DNDAfbBCAiUOFAy%2B@wood2.org.uk> <20110822094756.GJ92605@core.byshenk.net> <uccbrIC$ZjUOFAG1@wood2.org.uk> <20110824070826.GK92605@core.byshenk.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Greg, In message <20110824070826.GK92605@core.byshenk.net>, Greg Byshenk <freebsd@byshenk.net> writes >On Mon, Aug 22, 2011 at 11:59:11AM +0100, David Wood wrote: > >> In message <20110822094756.GJ92605@core.byshenk.net>, Greg Byshenk >> <freebsd@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 david@wood2.org.uk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?tDjrcvEEzNVOFAuY>