brian redbeard

Members
  • Content Count

    3
  • Joined

  • Last visited

About brian redbeard

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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. 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. 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.