On Sat, May 19, 2018 at 08:30:12AM +0200, Sebastien Marie wrote:
> Hi,
> 
> Working on lang/rust on arm64, I experiment rustc panic due to not
> monotonic timestamp. I tried to reproduce the problem in plain C.
> 
> My test program is just a loop of calling
> clock_gettime(CLOCK_MONOTONIC), and it checks if the result is monotonic
> (by comparing with previous value).
> 

Artturi Alm told me that it is a know hardware problem.

The proposed patch for Linux has good documentation about it.
https://patchwork.kernel.org/patch/10392885/

        The Allwinner A64 SoC is known [1] to have an unstable architectural
        timer, which manifests itself most obviously in the time jumping forward
        a multiple of 95 years [2][3]. This coincides with 2^56 cycles at a
        timer frequency of 24 MHz, implying that the time went slightly backward
        (and this was interpreted by the kernel as it jumping forward and
        wrapping around past the epoch).

        Further investigation revealed instability in the low bits of CNTVCT at
        the point a high bit rolls over. This leads to power-of-two cycle
        forward and backward jumps. (Testing shows that forward jumps are about
        twice as likely as backward jumps.)

        [...]

        Because the CPU can read the CNTPCT/CNTVCT registers faster than they
        change, performing two reads of the register and comparing the high bits
        (like other workarounds) is not a workable solution. And because the
        timer can jump both forward and backward, no pair of reads can
        distinguish a good value from a bad one. The only way to guarantee a
        good value from consecutive reads would be to read _three_ times, and
        take the middle value iff the three values are 1) individually unique
        and 2) increasing. This takes at minimum 3 cycles (125 ns), or more if
        an anomaly is detected.

        However, since there is a distinct pattern to the bad values, we can
        optimize the common case (2046/2048 of the time) to a single read by
        simply ignoring values that match the pattern. This still takes no more
        than 3 cycles in the worst case, and requires much less code.

        [1]: https://github.com/armbian/build/commit/a08cd6fe7ae9
        [2]: https://forum.armbian.com/topic/3458-a64-datetime-clock-issue/
        [3]: https://irclog.whitequark.org/linux-sunxi/2018-01-26

Reply via email to