[ntp:hackers] FreeBSD serial ports

[David L. Mills]

Greg,

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.

Dave

Greg Dowd wrote:

>Dave,
>	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
>would recover?
>
>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.
>
>
>-----Original Message-----
>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
>
>Folks,
>
>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
>previously.
>
>Dave
>
>_______________________________________________
>hackers mailing list
>hackers at support.ntp.org
>https://support.ntp.org/mailman/listinfo/hackers
>
>
>
>Greg Dowd
>  
>