[ntp:hackers] FreeBSD serial ports

Greg Dowd GDowd at symmetricom.com
Mon Feb 14 13:30:51 PST 2005


Here's the reply that I got from Dave talking about his serial driver.

>>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


What we were talking about is the refclock read routine in
ntpd/ntp_io.c's input_handler.  My primary problem was, and still is,
with the ACTS refclock driver.  There is still a bug, at least for
Linux, in that the value of &C is incorrectly set to &C0 (DCD override)
in the modem initialization string.  I thought I had convinced Dave when
the comment got updated but the code never did.  The end result is that
the serial code will return 0 (eof) if the phone line gets dropped.
This causes an endless loop in input_handler.

Anyway, looking at the input_handler refclock read routine, you'll see
that read will accept a 0 length receive and load it into a buf.  If the
input device keeps returning 0 length reads, the code loops until
exhausting all the buffers and then continues to loop discarding input.
A reference clock driver doesn't get a chance to notice or correct the
behavior as the upcall never happens unless the driver specifies a
io_rcv function to note the 0 length and return 0 which tells the
input_handler to drop the buffer.

For the acts ref clock driver, the easy fix is to correct the init
string.  For a belt and suspenders approach, the driver could hook
io_rcv and discard 0 length buffers.  

For the rest of the drivers and the io subsystem, I don't know.  I have
never seen a definition of the refclock io system interface other than
reading the code or asking Dave.  An occasional 0 length timeout and
read would, presumably, be handled by most functional drivers without
choking, although the acts and Dave's serial driver refute that.  Having
said that, I'm confused about what purpose a 0 length callback with
timestamp would serve.  

 


Greg Dowd
gdowd at symmetricom dot com (antispam format)
Technologist, TT&M Div.
Symmetricom, Inc. 
www.symmetricom.com




-----Original Message-----
From: Danny Mayer [mailto:mayer at gis.net] 
Sent: Friday, February 11, 2005 7:06 PM
To: Greg Dowd; David L. Mills; hackers at ntp.org
Subject: RE: [ntp:hackers] FreeBSD serial ports

At 12:27 PM 2/10/2005, 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.

Greg, can you send me detailed information on this? I'm in the process
of cleaning up the code.

Danny





More information about the hackers mailing list