[ntp:hackers] FreeBSD serial ports

David L. Mills mills at udel.edu
Tue Feb 15 05:38:56 PST 2005


Greg,

Let me be very clear. The explicit and purposeful intent is to use the 
given initialization string. The US modems don't work otherwise. It may 
well be that Europeans need to use a different one and I am warm to 
that. In any case, a zero length buffer should not hang the driver.

Dave

Greg Dowd wrote:

>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