From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 11:57:47 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D16553F; Tue, 28 Apr 2015 11:57:47 +0000 (UTC) Received: from mail-in-01.arcor-online.net (mail-in-01.arcor-online.net [151.189.21.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte SSL CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 43BAC11D9; Tue, 28 Apr 2015 11:57:46 +0000 (UTC) Received: from mail-in-13-z2.arcor-online.net (mail-in-13-z2.arcor-online.net [151.189.8.30]) by mx.arcor.de (Postfix) with ESMTP id 3lbhLG4n37z2m0H; Tue, 28 Apr 2015 13:57:42 +0200 (CEST) Received: from mail-in-17.arcor-online.net (mail-in-17.arcor-online.net [151.189.21.57]) by mail-in-13-z2.arcor-online.net (Postfix) with ESMTP id A13243C9D66; Tue, 28 Apr 2015 13:57:42 +0200 (CEST) X-Greylist: Passed host: 188.105.84.49 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-17.arcor-online.net 3lbhLG361Xz6HDl X-Greylist: Passed host: 188.105.84.49 Received: from lorvorc.mips.inka.de (dslb-188-105-084-049.188.105.pools.vodafone-ip.de [188.105.84.49]) by mail-in-17.arcor-online.net (Postfix) with ESMTPS id 3lbhLG361Xz6HDl; Tue, 28 Apr 2015 13:57:42 +0200 (CEST) Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.9/8.14.9) with ESMTP id t3SBvfsE068535; Tue, 28 Apr 2015 13:57:41 +0200 (CEST) (envelope-from naddy@lorvorc.mips.inka.de) Received: (from naddy@localhost) by lorvorc.mips.inka.de (8.14.9/8.14.9/Submit) id t3SBvfQ2068534; Tue, 28 Apr 2015 13:57:41 +0200 (CEST) (envelope-from naddy) Date: Tue, 28 Apr 2015 13:57:41 +0200 From: Christian Weisgerber To: Ian Lepore Cc: freebsd-hackers@freebsd.org Subject: Re: System clock always unsynced Message-ID: <20150428115741.GA68174@lorvorc.mips.inka.de> References: <1430177037.1157.23.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1430177037.1157.23.camel@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 11:57:47 -0000 Ian Lepore: > > Okay, let me rephrase this since the first two replies completely > > missed the point. This is an API programming question. How is the > > poorly documented ntp_adjtime() API to be used so the system clock > > will lose the STA_UNSYNC status and switch from TIME_ERROR to TIME_OK > > as clock state? > > It requires a call to ntp_adjtime() with the MOD_STATUS bit set in > ntv.modes and the STA_UNSYNC bit clear in ntv.status. Well, yes. You omitted the crucial piece of information, but I think I have figured it out from reading kern_ntptime.c: The STA_UNSYNC value is _read_ by the kernel and (mostly) _set_ by userland. It is ntpd that is supposed to clear STA_UNSYNC to signal the kernel that the time is synchronized. The ntp_adjtime(2) man page doesn't say anything how STA_UNSYNC is used and I had naturally assumed that it was the kernel that cleared STA_UNSYNC to let ntpd know (that the offsets had been applied or whatever). -- Christian "naddy" Weisgerber naddy@mips.inka.de