[ntp:hackers] FreeBSD serial ports

mayer at gis.net mayer at gis.net
Mon Feb 14 14:45:52 PST 2005


----- Original Message Follows -----
> 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.  
> 

Probably because I only check this in this weekend. The looping problem
should also be fixed. If not please let me know. It was all a very
nasty mess. You should also have seen this in my response to your bug
report #367.

Danny

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