Date suddenly changed to 2114

[mossroy]

I just had this same issue again on a very recent image from olimex (A64-OLinuXino-buster-minimal-20201008-174232.img.7z).

Same symptom : date jumps in 2015 (December 23) and the ethernet network is stopped.

This is a very big problem on headless servers, as they become unreachable.

Here is an excerpt of syslog :

Code Select Expand

Oct 29 23:34:05 a64-olinuxino kernel: [1324864.326498] rcu: INFO: rcu_sched self-detected stall on CPU
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.332258] rcu:     3-...!: (1 ticks this GP) idle=b06/0/0x1 softirq=309435/309435 fqs=0
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.340422]  (t=11812 jiffies g=1294529 q=30)
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.340430] rcu: rcu_sched kthread starved for 11812 jiffies! g1294529 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=3
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.351106] rcu:     Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior.
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.360221] rcu: RCU grace-period kthread stack dump:
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365437] rcu_sched       I    0    10      2 0x00000028
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365446] Call trace:
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365462]  __switch_to+0xf8/0x198
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365474]  __schedule+0x238/0x670
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365480]  schedule+0x58/0xe8
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365487]  schedule_timeout+0x180/0x398
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365496]  rcu_gp_kthread+0x410/0xb60
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365502]  kthread+0x12c/0x130
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365508]  ret_from_fork+0x10/0x30
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365518] Task dump for CPU 0:
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365522] swapper/0       R  running task        0     0      0 0x00000028
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365529] Call trace:
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365536]  __switch_to+0xf8/0x198
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365541]  0x0
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365545] Task dump for CPU 1:
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365548] swapper/1       R  running task        0     0      1 0x0000002a
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365555] Call trace:
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365561]  __switch_to+0xf8/0x198
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365565]  0x0
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365569] Task dump for CPU 3:
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365572] swapper/3       R  running task        0     0      1 0x0000002a
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365578] Call trace:
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365586]  dump_backtrace+0x0/0x1b8
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365593]  show_stack+0x20/0x30
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365600]  sched_show_task+0x150/0x180
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365607]  dump_cpu_task+0x4c/0x60
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365613]  rcu_dump_cpu_stacks+0xc4/0x10c
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365618]  rcu_sched_clock_irq+0x7c0/0x9b0
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365627]  update_process_times+0x38/0x98
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365636]  tick_sched_handle.isra.19+0x48/0x58
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365642]  tick_sched_timer+0x54/0xb0
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365647]  __hrtimer_run_queues+0x10c/0x360
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365652]  hrtimer_interrupt+0x11c/0x2f0
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365662]  arch_timer_handler_phys+0x38/0x48
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365670]  handle_percpu_devid_irq+0x94/0x240
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365677]  generic_handle_irq+0x38/0x50
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365682]  __handle_domain_irq+0x6c/0xc8
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365688]  gic_handle_irq+0x5c/0xb8
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365693]  el1_irq+0xb8/0x140
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365699]  arch_cpu_idle+0x40/0x1d8
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365704]  default_idle_call+0x3c/0x60
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365711]  do_idle+0x228/0x2a0
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365717]  cpu_startup_entry+0x2c/0x98
Oct 29 23:34:05 a64-olinuxino kernel: [1324864.365726]  secondary_start_kernel+0x15c/0x170
Oct 29 23:35:01 a64-olinuxino CRON[26942]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.590436] rcu: INFO: rcu_sched self-detected stall on CPU
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.596203] rcu:     1-...0: (1 GPs behind) idle=c9e/0/0x1 softirq=340248/340249 fqs=2
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604115]  (t=750629252211 jiffies g=1294529 q=2003)
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604121] Task dump for CPU 1:
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604127] swapper/1       R  running task        0     0      1 0x0000002a
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604136] Call trace:
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604152]  dump_backtrace+0x0/0x1b8
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604162]  show_stack+0x20/0x30
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604170]  sched_show_task+0x150/0x180
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604178]  dump_cpu_task+0x4c/0x60
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604185]  rcu_dump_cpu_stacks+0xc4/0x10c
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604190]  rcu_sched_clock_irq+0x7c0/0x9b0
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604198]  update_process_times+0x38/0x98
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604207]  tick_sched_handle.isra.19+0x48/0x58
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604213]  tick_sched_timer+0x54/0xb0
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604219]  __hrtimer_run_queues+0x10c/0x360
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604224]  hrtimer_interrupt+0x11c/0x2f0
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604234]  arch_timer_handler_phys+0x38/0x48
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604243]  handle_percpu_devid_irq+0x94/0x240
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604249]  generic_handle_irq+0x38/0x50
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604255]  __handle_domain_irq+0x6c/0xc8
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604260]  gic_handle_irq+0x5c/0xb8
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604265]  el1_irq+0xb8/0x140
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604272]  arch_cpu_idle+0x40/0x1d8
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604281]  default_idle_call+0x3c/0x60
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604288]  do_idle+0x228/0x2a0
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604294]  cpu_startup_entry+0x30/0x98
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604302]  secondary_start_kernel+0x15c/0x170
Dec 23 08:04:14 a64-olinuxino kernel: [1325159.604357] hrtimer: interrupt took 3002517008854765534 ns
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.150574] rcu: INFO: rcu_sched self-detected stall on CPU
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.156334] rcu:     1-...!: (3 ticks this GP) idle=5b6/1/0x4000000000000002 softirq=348968/348970 fqs=1
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.165800]  (t=12887 jiffies g=1311021 q=624)
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.165808] rcu: rcu_sched kthread starved for 12885 jiffies! g1311021 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.176486] rcu:     Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior.
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.185603] rcu: RCU grace-period kthread stack dump:
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.190823] rcu_sched       I    0    10      2 0x00000028
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.190834] Call trace:
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.190852]  __switch_to+0xf8/0x198
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.190864]  __schedule+0x238/0x670
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.190871]  schedule+0x58/0xe8
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.190878]  schedule_timeout+0x180/0x398
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.190890]  rcu_gp_kthread+0x410/0xb60
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.190896]  kthread+0x12c/0x130
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.190903]  ret_from_fork+0x10/0x30
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.190932] Task dump for CPU 1:
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.190937] systemd-journal R  running task        0 16594      1 0x00000802
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.190946] Call trace:
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.190954]  dump_backtrace+0x0/0x1b8
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.190961]  show_stack+0x20/0x30
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.190968]  sched_show_task+0x150/0x180
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.190976]  dump_cpu_task+0x4c/0x60
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.190981]  rcu_dump_cpu_stacks+0xc4/0x10c
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.190987]  rcu_sched_clock_irq+0x7c0/0x9b0
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.190997]  update_process_times+0x38/0x98
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.191007]  tick_sched_handle.isra.19+0x48/0x58
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.191013]  tick_sched_timer+0x54/0xb0
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.191018]  __hrtimer_run_queues+0x10c/0x360
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.191023]  hrtimer_interrupt+0x11c/0x2f0
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.191034]  arch_timer_handler_phys+0x38/0x48
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.191044]  handle_percpu_devid_irq+0x94/0x240
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.191050]  generic_handle_irq+0x38/0x50
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.191056]  __handle_domain_irq+0x6c/0xc8
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.191061]  gic_handle_irq+0x5c/0xb8
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.191066]  el1_irq+0xb8/0x140
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.191074]  ___bpf_prog_run+0xad8/0x19e0
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.191079]  __bpf_prog_run32+0x44/0x68
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.191090]  __seccomp_filter+0x88/0x620
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.191097]  __secure_computing+0x44/0xd0
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.191104]  syscall_trace_enter+0x1a4/0x1d8
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.191113]  el0_svc_common.constprop.3+0x60/0x178
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.191120]  do_el0_svc+0x2c/0x98
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.191126]  el0_sync_handler+0x148/0x1a8
Dec 23 08:05:31 a64-olinuxino kernel: [1325237.191131]  el0_sync+0x158/0x180
Dec 23 08:12:34 a64-olinuxino kernel: [1325659.690143] power_supply axp813-ac: driver failed to report `online' property: -110
Dec 23 08:12:53 a64-olinuxino kernel: [1325678.545378] rcu: INFO: rcu_sched self-detected stall on CPU
Dec 23 08:12:53 a64-olinuxino kernel: [1325678.551136] rcu:     0-...0: (7045096 ticks this GP) idle=22e/1/0x4000000000000002 softirq=631070/631074 fqs=2422
Dec 23 08:12:53 a64-olinuxino kernel: [1325678.561381]  (t=5253 jiffies g=1391941 q=6452)
Dec 23 08:12:53 a64-olinuxino kernel: [1325678.561385] Task dump for CPU 0:
Dec 23 08:12:53 a64-olinuxino kernel: [1325678.561390] systemd-journal R  running task        0 16594      1 0x00000802
Dec 23 08:12:53 a64-olinuxino kernel: [1325678.561400] Call trace:
Dec 23 08:12:53 a64-olinuxino kernel: [1325678.561416]  dump_backtrace+0x0/0x1b8
Dec 23 08:12:53 a64-olinuxino kernel: [1325678.561425]  show_stack+0x20/0x30
Dec 23 08:12:53 a64-olinuxino kernel: [1325678.561433]  sched_show_task+0x150/0x180
Dec 23 08:12:53 a64-olinuxino kernel: [1325678.561440]  dump_cpu_task+0x4c/0x60
Dec 23 08:12:53 a64-olinuxino kernel: [1325678.561447]  rcu_dump_cpu_stacks+0xc4/0x10c
Dec 23 08:12:53 a64-olinuxino kernel: [1325678.561453]  rcu_sched_clock_irq+0x7c0/0x9b0
Dec 23 08:12:53 a64-olinuxino kernel: [1325678.561461]  update_process_times+0x38/0x98
Dec 23 08:12:53 a64-olinuxino kernel: [1325678.561470]  tick_sched_handle.isra.19+0x48/0x58
Dec 23 08:12:53 a64-olinuxino kernel: [1325678.561476]  tick_sched_timer+0x54/0xb0
Dec 23 08:12:53 a64-olinuxino kernel: [1325678.561481]  __hrtimer_run_queues+0x10c/0x360
Dec 23 08:12:53 a64-olinuxino kernel: [1325678.561486]  hrtimer_interrupt+0x11c/0x2f0
Dec 23 08:12:53 a64-olinuxino kernel: [1325678.561496]  arch_timer_handler_phys+0x38/0x48
Dec 23 08:12:53 a64-olinuxino kernel: [1325678.561505]  handle_percpu_devid_irq+0x94/0x240
Dec 23 08:12:53 a64-olinuxino kernel: [1325678.561511]  generic_handle_irq+0x38/0x50
Dec 23 08:12:53 a64-olinuxino kernel: [1325678.561517]  __handle_domain_irq+0x6c/0xc8
Dec 23 08:12:53 a64-olinuxino kernel: [1325678.561522]  gic_handle_irq+0x5c/0xb8
Dec 23 08:12:53 a64-olinuxino kernel: [1325678.561528]  el0_irq_naked+0x4c/0x54

[JohnS]

This sounds like the bug in the A64 chip which Linux tries to work around - I'm not sure if the workaround actually works.

You can read about it in posts on the linux-sunxi ML and probably elsewhere.

John

[mossroy]

This issue is still there.

I recently had it on the latest kernel 5.8.18 (see https://www.olimex.com/forum/index.php?topic=7976.msg30112#msg30112).
And today I had it on kernel 5.10.4 (from "staging" repository of olimex) : my board jumped to Thu 27 Feb 23:48:54 CET 2116

[mossroy]

There must be a software way to fix or workaround this issue, because some of my boards do not seem to have it (at least I don't remember they had it)

Here is some detail :
- board 1, installed with image A64-OLinuXino-buster-minimal-20200522-193443.img, with kernel 5.8.18 : stable
- board 2, installed with Armbian_5.92.1_Olinuxino-a64_Debian_buster_next_5.2.5.img, kernel 5.2.5 : stable
- board 3, installed with A64-OLinuXino-buster-minimal-20200601-131837.img, with kernel 5.8.18 : stable
- board 4, installed with A64-OLinuXino-buster-minimal-20201207-193928.img, with kernel  5.8.18 : timer issue
- board 5, installed with A64-OLinuXino-buster-minimal-20201207-193928.img, with kernel  5.10.4 (from staging olimex repository) : timer issue

Only the last two boards, freshly installed with a recent image, recently had the timer issue.

You can see in some other posts I did here that I also had the timer issue with image A64-OLinuXino-buster-minimal-20201008-174232.img and image A64-OLinuXino-buster-minimal-20201217-194545.img

Could it be possible that recent images have a regression on the timer issue?

Of course, there might be other factors, I'm not sure at all.

[LubOlimex]

Could it be possible that recent images have a regression on the timer issue?

Yes, because the workaround to fix the time jump issue caused sluggishness that affected everything else. So no workaround applied in latest releases. We are waiting for a better workaround that doesn't cause bigger issues.

Doesn't enabling NTP work for you?

[mossroy]

ntp status depends on the board :
- board 1 : systemd-timesyncd does not start because of a systemd condition : "ConditionFileIsExecutable=!/usr/sbin/ntpd was not met". ntp service is running but reports "kernel reports TIME_ERROR: 0x41: Clock Unsynchronized"
- board 2 : systemd-timesyncd does not start because of a systemd condition : "ConditionFileIsExecutable=!/usr/sbin/ntpd was not met". ntp service is running but reports "kernel reports TIME_ERROR: 0x41: Clock Unsynchronized"
- board 3 : systemd-timesyncd running
- board 4 : systemd-timesyncd running
- board 5 : systemd-timesyncd running

Please advise on what would be the right way to configure NTP, if it could be a workaround.

[mossroy]

Regarding the sluggishness of recent images, I'm aware of that issue.
On the other hand, changing the governor to something different than "ondemand" seemed to be a workaround.

IMHO, leaving the timer issue in your images is much worse than forcing the governor in them.

As already explained here, the timer jump symptom has critical consequences when you use the board as a headless server (which is my case) :

• the board looses its network access : you can not fix it remotely. You have to physically plug a debug cable, and login in console mode to change the date back
• some software does not support this time change gracefully. Sometimes "touching" the files to set their last modification date is enough. Sometimes it's not : in particular, I did not manage to fix prometheus data, which is considered corrupt

[JohnS]

Just out of interest, are you having this discussion with the people responsible for the software (linux-sunxi people) as well, because they need to know your actual experience don't they?

Of course the real problem is the faulty silicon CPU from Allwinner...

John

[mossroy]

I did not contact linux-sunxi. I'm not 100% sure it only comes from the kernel (see the detail of my boards in a post above : some have the same kernel and not the same behavior).

I would expect Olimex to do what is necessary to provide the right images.

I know the original issue is a hardware one in the Allwinner A64 CPU. But Olimex has IMHO a responsibility to sell usable boards (stable, secure, with reasonably up-to-date software, able to use all the hardware capabilities, upgradable, etc).
They also have enough boards to test (I don't), precise knowledge of their images and their roadmap.

I'm still willing to help if/when I can. I try to give precise feedback when I see problems, with possible solutions when I can.

On the other hand, I bought my boards to actually use them. I did not expect to be a beta-tester of Olimex images, 2 years after I bought my first one.
I'm running many things on them and need them to be stable servers.
I can't keep unstable boards to test workarounds. For example I'm currently reinstalling my boards 4 and 5 with older images to make them stable again : sorry if it's a loss of a test-case but I don't have a choice.

I'm also a bit disappointed by the recent problems in Olimex images (see latest A64 topics). Most of them could have been avoided with more checking/testing on Olimex side IMHO. I'm also disappointed by the many "soon" timelines given by Olimex, that are too vague to plan, and sometimes become a "never".

Anyway, I'm still trying to stay positive and I don't understimate the difficulty on Olimex side. I'm very happy with my A20 Olinuxino boards, that are stable and 100% working on Debian for years now. I hope it will happen soon with A64 ones, and that I will be able to continue to be an Olinuxino supporter.

[JohnS]

So far as I can tell no-one can do what you ask unless Allwinner issue working chips but you can get a better answer from devs on linux-sunxi I guess.

John

[LubOlimex]

We will probably try to revert the clock changes and set "performance" governor, something that you reported as working.

Unfortunately, we can't test all the things all the time. Especially, since we are trying to move forward to newer kernels and some new issues get introduced.

We can provide something outdated and tested that would never move forward and would probably have everything working.

[olimex]

@mossroy we really appreciate your feedback and efforts.

Linux never have been our strong side and we rely on Linux-Sunxi community mostly for the software support. We have two developers who work on the Linux images but we can only do what we can do - all patches we do are submitted upstream only for the issues we understand and can fix.

This clock bug for A64 is not Olimex board specific, it is also in all current Linux distributions and same in all A64 boards in the market. It will be fixed when someone who know how to fix it do it. DO not expect from us more than we can do.

What we can do is to discuss with you and other customers which work arond works best for as many of you as possible.

In this case the frequency may be set to performance which means processor will waste too much energy and power or to minimal. Both are not universal solution. Our people wrongly assumed the date problem is minor to the flexibility to change processor performance over the time.

Again we appreciate your feedback, please do not be disappointed by us, just this issue behind our capabilities to fix.

[mossroy]

Thanks for your answers.

I'm OK to participate in the discussion you mentioned, to try to find an acceptable solution for most customers.
My usage (as headless servers) is certainly not representative of all your customers, so you'll need to have feedback from other ones, too.

We might be not very far from the goal, because I already have some A64 boards that are working, seem stable (for my usage), and use the default ondemand governor (boards 1 and 3).

I personally don't need a kernel newer than 5.6. I just need future patches on the kernel, without regression risks.
If some customers need a cutting-edge kernel, you might provide an easy way to upgrade it (by activating a new repository, like "staging"?), while keeping a stable one by default.

Olimex is responsible for providing suitable images for their boards (at least until the boards are fully supported by Debian installer, which unfortunately will not yet be the case with Debian 11 Bullseye).

Your community/customers can help, but the communication with them (us) needs IMHO to be improved. It's sometimes hard to have precise answers (or even answers), or to know what has changed between 2 versions, or to have information on your roadmap.
And changes have to be tested enough to be safe.

[mossroy]

Your community/customers can help, but the communication with them (us) needs IMHO to be improved. It's sometimes hard to have precise answers (or even answers), or to know what has changed between 2 versions, or to have information on your roadmap.

I see that a new image http://images.olimex.com/release/a64/A64-OLinuXino-buster-minimal-20210127-100834.img.7z is now available
Could you tell us the changes that have been made?

Some of the changes can be found on https://github.com/OLIMEX/olimage/commits/master , but I suppose it's not all of them? (and sometimes the commit comments don't give the purpose of the change)

I would suggest to provide a changelog for each version, and announce these new versions somewhere (sorry if it's already done and I missed it?)

NB : I'm still available for the discussion you mentioned

[LubOlimex]

Mainly updated u-boot 2021.01 and kernel to 5.10.x, the rest can be seen, as you mentioned, here:

https://github.com/OLIMEX/olimage/commits/master