From owner-freebsd-current@FreeBSD.ORG Mon Jun 30 17:02:05 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A1721065670 for ; Mon, 30 Jun 2008 17:02:05 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 84F948FC1F for ; Mon, 30 Jun 2008 17:02:04 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m5UH22T0099106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Jun 2008 19:02:03 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id m5UH1rFY064361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jun 2008 19:01:54 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id m5UH1r18024640; Mon, 30 Jun 2008 19:01:53 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id m5UH1rrM024639; Mon, 30 Jun 2008 19:01:53 +0200 (CEST) (envelope-from ticso) Date: Mon, 30 Jun 2008 19:01:53 +0200 From: Bernd Walter To: Aragon Gouveia Message-ID: <20080630170152.GS17364@cicely7.cicely.de> References: <20080630151740.GQ17364@cicely7.cicely.de> <20080630155138.GA3084@phat.za.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080630155138.GA3084@phat.za.net> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.068, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-current@freebsd.org, ticso@cicely.de Subject: Re: RTC problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2008 17:02:05 -0000 On Mon, Jun 30, 2008 at 05:51:38PM +0200, Aragon Gouveia wrote: > adjkerntz(8) ? adjkerntz, as is, does this only when doing daylight switching. This is only true for systems running their RTC on localtime. Without starting a discussion about running your RTC on localtime vs UTC - some RTC chips can only do UTC. > | By Bernd Walter > | [ 2008-06-30 17:30 +0200 ] > > This is not about a specific hardware - I have a general problem. > > Normaly I run ntpdate and ntpd - ntpdate sets the time on boot and > > then ntpd takes over to keep it in sync. > > What recently happend was that a server with a multiple years uptime > > rebootet because of a power failure and the local ntp-server wasn't > > up early enough, so ntpdate didn't set the clock. > > ntpd didn't tune the clock either, because the offset was too big. > > I know from debugging RTC support on arm, that the RTC only gets > > written on explizit time setting with ntpdate, date and such. > > But since ntpd only tunes the softclock and never sets the RTC it > > allows the RTC to run completely unsyncronized. > > Is there a way to regulary trigger a write to the RTC without > > disturbing ntpd, so that the offset never gets large? > > Of course I can configure ntpd to accept a large offset, but it seems > > wrong to me that the RTC runs unsyncronized for a large time. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.