brian redbeard

Members
  • Content Count

    3
  • Joined

  • Last visited

  1. brian redbeard

    A64 date/time clock issue

    Related to the other date time thread, I spent some time digging through patchwork and found that Andre Przywara has put together a useful utility for testing the issue: test_timer.c After pulling it down and compiling it: gcc -o test_timer test_timer.c Digging into this further, but at least there's a utility to use with some patches to check to see if the issue gets resolved.
  2. brian redbeard

    pine64: massive date/time clock problem

    Also curious, 1551794590 seems to be the last time at which the system clock may have made a checkpoint via systemd-timesyncd on a previous reboot before going back to the future. $ date --date='@1551794590' Tue Mar 5 06:03:10 PST 2019 And a snippet from kern.log showing the current boot time: Mar 5 06:12:58 string kernel: [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] Mar 5 06:12:58 string kernel: [ 0.000000] Linux version 4.19.20-sunxi64 (root@armbian.com) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #5.75 SMP Fri Feb 8 10:29:25 CET 2019
  3. brian redbeard

    pine64: massive date/time clock problem

    I decided to dig into this since I was seeing the same issue. root@string:~# uname -r 4.19.20-sunxi64 root@string:~# dpkg -s linux-image-next-sunxi64 Package: linux-image-next-sunxi64 Status: install ok installed Priority: optional Section: kernel Installed-Size: 87123 Maintainer: Igor Pecovnik <igor.pecovnik@****l.com> Architecture: arm64 Source: linux-4.19.20-sunxi64 Version: 5.75 Description: Linux kernel, version 4.19.20-sunxi64 This package contains the Linux kernel, modules and corresponding other files, version: 4.19.20-sunxi64. Homepage: http://www.kernel.org/ root@string:~# grep CONFIG_FSL_ERRATUM_A008585 /boot/config-4.19.20-sunxi64 CONFIG_FSL_ERRATUM_A008585=y root@string:~# date Sat Apr 28 02:43:25 UTC 2114 root@string:~# timedatectl Local time: Sat 2114-04-28 02:43:30 UTC Universal time: Sat 2114-04-28 02:43:30 UTC RTC time: Tue 2019-03-05 22:21:31 Time zone: Etc/UTC (UTC, +0000) System clock synchronized: no systemd-timesyncd.service active: no RTC in local TZ: no root@string:~# hwclock -s hwclock: settimeofday() failed: Invalid argument I decided to do a much more simple test: I can see that the when date attempts to make the clock_settime syscall, it receives EINVAL back. I'm wondering then why it sees CLOCK_REALTIME as invalid. I could potentially see an issue with CLOCK_REALTIME_COARSE which man 2 CLOCK_GETRES says is "architecture specific", but this one is throwing me of.