[ntp:hackers] FreeBSD serial ports

Greg Dowd GDowd at symmetricom.com
Mon Feb 14 13:48:41 PST 2005


Sorry, my bad. The code is right, the comment is wrong on the acts modem
init string in the latest dev pull.  &C0 is correct, DCD always on.  The
comment needs to change to &C0 as well.  


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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material.  Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient are prohibited.   If you
received this in error, please contact the sender and delete the
material from any computer.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



-----Original Message-----
From: hackers-bounces at support.ntp.org
[mailto:hackers-bounces at support.ntp.org] On Behalf Of Greg Dowd
Sent: Monday, February 14, 2005 1:31 PM
To: Danny Mayer; David L. Mills; hackers at ntp.org
Subject: RE: [ntp:hackers] FreeBSD serial ports

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


_______________________________________________
hackers mailing list
hackers at support.ntp.org
https://support.ntp.org/mailman/listinfo/hackers




More information about the hackers mailing list