[ntp:hackers] FreeBSD serial ports
David L. Mills
mills at udel.edu
Thu Feb 10 09:56:50 PST 2005
The code should return a zero length buffer anyway, as that conforms to
the Unix termios semantics. In raw mode the ioctl specifies the number
of characters and/or the time to wait. What happens here is there are no
characters and the timer expires.
I expect the bug has been around for a long time, as there have been
occasions when these symptoms appear with no clear explanation.
Greg Dowd wrote:
> That may be fixed by changing the 0 length read to drop the
>recvbuf and continue. That fix didn't work for ACTS since the daemon
>would hard loop there forever since 0 length read meant eof without &C
>change. If the problem is a momentary glitch in hardware, perhaps it
>The daemon really shouldn't be allocating a recvbuf on a 0 length read
>anyway, should it? There's no state that I know of where you would need
>to timestamp the hangup in refclock.
>From: hackers-bounces at support.ntp.org
>[mailto:hackers-bounces at support.ntp.org] On Behalf Of David L. Mills
>Sent: Thursday, February 10, 2005 8:52 AM
>To: hackers at ntp.org
>Subject: [ntp:hackers] FreeBSD serial ports
>I find that some, but not all, FreeBSD machines hang in a loop when
>first coming up with a reference clock connected. If linked via cuaa1,
>for instance, when coming up with the clock connected, the "too many
>recbufs" line shows up several times and then hangs. With the clock not
>connected, it comes up normally. If the clock is connected after the
>daemon is started, it works correctly.
>I suspect this problem is related to the problem with ACTS mentioned
>hackers mailing list
>hackers at support.ntp.org
More information about the hackers