linux-kernel - Re: 500 ms delay in time saved into RTC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 19 Feb 2018 08:11:05 +0100
From:   Rasmus Villemoes <rasmus.villemoes@...vas.dk>
To:     Igor Plyatov <plyatov@...il.com>, <linux-kernel@...r.kernel.org>,
        Alessandro Zummo <a.zummo@...ertech.it>,
        Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
        <rtc-linux@...glegroups.com>
CC:     <util-linux@...r.kernel.org>
Subject: Re: 500 ms delay in time saved into RTC

On 2018-02-19 07:40, Igor Plyatov wrote:
> Hi!
> 
> I have board based on AT91SAM9G20 (ARM926EJ-S CPU), Linux-4.9.36 kernel
> and RTC chip DS1340 (rtc-ds1307.c driver).
> 
> RTC chip connected by means of I2C-bus, without HW IRQ line connected.
> 
> Kernel configured to not use embedded functions for time getting at
> startup and saving at shutdown:
> CONFIG_RTC_CLASS=y
> # CONFIG_RTC_HCTOSYS is not set
> # CONFIG_RTC_SYSTOHC is not set
> CONFIG_RTC_INTF_DEV_UIE_EMUL=y
> CONFIG_RTC_DRV_DS1307=y
> CONFIG_RTC_DRV_DS1307_CENTURY=y
> 
> The hwclock utility is from util-linux-2.29.1.
> 
> The OS does not have external time synchronization sources like NTP, PTP
> or else.
> 
> Generally I need to achieve error within +-20 ms when RTC's time copied
> into OS or back from OS into RTC.
> 
> I have made measurements during startup and shutdown of OS and have
> found 500 ms delay introduced into RTC's time, when "hwclock --utc
> --systohc" executed.
> 
> Logical analyzer show to me I2C-bus transactions and PPS signal
> generated by Linux. And I see 500 ms delay is between of rising edge of
> PPS signal (start of OS second) and moment when time saved into RTC.
> 
> Please explain, why this happens? Is this due to absence of IRQ line for
> RTC or due to a bug in the hwclock, or kernel bug or I have missed
> something else?

cc += util-linux@...r.kernel.org

It's because util-linux's hwclock still assumes the world is x86. See
this comment in the util-linux source code:

        /*
         * The Hardware Clock can only be set to any integer time plus one
         * half second.  The integer time is required because there is no
         * interface to set or get a fractional second.  The additional half
         * second is because the Hardware Clock updates to the following
         * second precisely 500 ms (not 1 second!) after you release the
         * divider reset (after setting the new time) - see description of
         * DV2, DV1, DV0 in Register A in the MC146818A data sheet (and note

So if hwclock is asked to --systohc at time 01:02:03.x, it waits until
the time is 01:02:03.5 to set the rtc to 01:02:03, or if that has
already passed, waits until  01:02:04.5 and sets it to 01:02:04.

On our ARM BSP we patch util-linux to have the "implicit fractional
part" configurable, and trying to upstream something like that has been
on my todo-list for quite a while. See

https://raw.githubusercontent.com/oe-lite/base/master/recipes/util-linux/util-linux-2.29/hwclock-tweak-delay.patch

for the patch we currently use (on top of that, we change the 0.5
initializer to 0.0 to avoid having to always pass the --delay argument).
Incidentally, it seems we're on the same util-linux version, so you
should be able to try out that patch and see if it works for you.

Rasmus