• Content Count

  • Joined

  • Last visited

  1. No, they're not. Three separate systems: two Pine A64+ systems and one Pine A64-LTS. And they've now been running for over 54 days.
  2. Update: It's been a little over two weeks now, and all three of my Pines are running Ubuntu 20.04 LTS with the 5.4-43 kernel, and all have been running without problem.
  3. I attempted to upgrade one of my Pines running 4.19 to 20.04 LTS. It didn't complain, but I discovered when it rebooted that the installation had wiped out several files in my /boot directory. No idea why, but I couldn't recover from it. I ended up just starting from scratch with the Armbian Focal distribution. I'm now running that on two of my three Pines (I finally gave up on the fourth one, as it kept having various hardware issues). It's only been a couple of days, but there've been no time jumps yet with the new kernel (5.4-43).
  4. It's now May 26. None of my Pine systems has time-jumped since going to 5.3.9 and patched 4.19.83 as described in my March 25 post. I still have not retried 5.4 or higher. FWIW.
  5. Interesting. I finally took the time to pull down the current Armbian kernel code and build it so I could see what's in there. The post-build arm_arch_timer.c files are identical for my patched 4.19.83 and the sources I got with "git clone" this morning, which means that the patch is included in the current sources. But I have other issues with 5.4.20, as I documented above, so maybe 5.4.20 does solve the time-jump problem, and I just don't know it because I haven't run it long enough (because of the other problems: kworker processes chewing up CPU time when idle, incorrect CPU tem
  6. Link sent. If anyone else wants them, let me know. Hunter
  7. And the system described above jumped again today. When I rebooted it, this is what I saw. root@zako:~# hwclock && date 1969-12-31 18:00:38.270548-0600 Tue Mar 24 14:41:14 CDT 2020 root@zako:~# I have now gone back to the patched 4.19.83 on the two systems that keep jumping, and there they shall stay. So far, my other two have not jumped since going to 5.3.9. If either does, I'll move it back to the patched 4.19.83.
  8. After my last post, I made a discovery that seems to have helped with the time jump problem. So much so that I rescued my decommissioned fourth Pine from the recycle bin to give it one more go. I learned about the hwclock command to display and set the hardware clock. Long story short, I used this sequence to set my clocks on Pine #3, the one that I said on the 10th took me several "set time/reboot" sequences: $ hwclock $ ntpdate pool.ntp.org $ hwclock -w $ hwclock && date The first "hwclock" just displays the hardware clock setting. The two clocks differed by a few
  9. After about 10 days, two of my Pines are stable. The third one keeps time jumping. This morning, it took me several "set time/reboot" sequences before I was finally able to stop it from time jumping. There's clearly still a problem in 5.3.9 with some AllWinner clocks. The patch posted earlier in this thread still seems to be the best workaround to this problem, even if some think it isn't the correct workaround. I have not tried to patch 5.3.9 with that patch, though I may give it a try if I continue to have problems.
  10. A week or so after I posted that, 5.5-rc6 was apparently pulled? Abandoned? It was no longer an option in the "switch kernels" section of armbian-config. I decided it was bad to run something that was apparently pulled, so I took my Pine A64+ systems to 5.3.9, and a day or two later, apt upgrade bumped them to 5.4.20. But that was bad. My Ethernet speeds dropped to about 1/5 of what they normally are, and my Pine running Plex was constantly showing Plex processes using as much as 20% of the CPUs all the time. Last night, I finally rolled back to the 5.3.9 kernel (build 19.x.x), and
  11. It looks like it. After posting that, the system jumped ahead 95 years on Saturday morning. That was on 5.3. I decided to take all of my systems to 5.5-rc6. I haven't seen the issue on any of them since (though the CPU frequency still shows as 0 in htop on all four).
  12. Yeah, jumping forward about 95 years is what I'd always seen before. That system hasn't done it since I posted on Monday.
  13. Ouch. Two hours after I posted that, one of my Pine64s running 5.3.9 went back in time to 1979, apparently. A reboot cleared that. I've only seen date problems on this system three times. Once was early this morning, which prompted me to do the upgrade, as it was still running an unpatched 4.x, and then again this afternoon.
  14. I upgraded my four Pine64s (one LTS) to 5.3.9 today. So far, so good, re: clock problems. However, the Pine that I had the most clock problems with kept hanging while trying to edit files. I tried to go back to my patched kernel, but lost the CPU temperature and frequency. I also had problems with kworker processes using lots of CPU time. I speculated that it probably had something to do with the Ethernet port, as I've had problems with that before. I decided to try 5.5-rc6 and see what happened. No hanging, CPU temp is back, but the CPU frequencies show as just 0 (N/A in armbianmonitor). Sti
  15. @ams.br Allow me to join the chorus. Thank you for posting your easy-to-follow instructions. I was able to build the current Armbian kernel with your patch and install it without any issue at all. The system has been up 1 day and 11 hours. I finally took the step of installing your patch after the system time-jumped twice over the weekend. I can't say for sure yet that it fixes the problem for me, but I can say that your directions made it a piece of cake to build and install, and so far, so good. Thanks! Updated 2019-11-18: My patched Pine has been running for