11 11
linda

pine64: massive date/time clock problem

Recommended Posts

1 hour ago, Igor said:

 

Use updated build engine - do git pull before starting. I just build this kernel successfully.

That worked, the patch is applied, let's see if it works :)

Thanks!

Share this post


Link to post
Share on other sites
On 12/16/2019 at 6:30 PM, eminguez said:

That worked, the patch is applied, let's see if it works :)

Thanks!

I can confirm it's been >24h without the issue \o/ Also I've seen linux-image-dev-sunxi64/buster 19.11.4.351 contains the fix, so I'm upgrading to that package version instead my custom compiled one.

 

Thanks!

Share this post


Link to post
Share on other sites
Quote

Dec 23 13:35:02 localhost nm-dispatcher: req:2 'connectivity-change': new request (2 scripts)
Dec 23 13:35:02 localhost nm-dispatcher: req:2 'connectivity-change': start running ordered scripts...
Dec 23 13:35:03 localhost systemd[1]: Started Samba NMB Daemon.
Dec 23 13:35:03 localhost systemd[1]: Starting Samba SMB Daemon...
Dec 23 13:35:03 localhost systemd[1]: Started Samba SMB Daemon.
Dec 23 13:35:05 localhost chronyd[1037]: Selected source x.x.x.x
Dec 23 13:35:05 localhost chronyd[1037]: System clock wrong by -1.542673 seconds, adjustment started
Dec 23 13:35:05 localhost chronyd[1037]: System clock was stepped by -1.542673 seconds
Dec 23 13:35:10 localhost systemd[1]: NetworkManager-dispatcher.service: Succeeded.
Dec 23 13:35:16 localhost systemd[1]: systemd-hostnamed.service: Succeeded.
Dec 23 13:35:18 localhost systemd[1]: dev-ttyFIQ0.device: Job dev-ttyFIQ0.device/start timed out.
Dec 23 13:35:18 localhost systemd[1]: Timed out waiting for device /dev/ttyFIQ0.
Dec 23 13:35:18 localhost systemd[1]: Dependency failed for Serial Getty on ttyFIQ0.
Dec 23 13:35:18 localhost systemd[1]: serial-getty@ttyFIQ0.service: Job serial-getty@ttyFIQ0.service/start failed with result 'dependency'.
Dec 23 13:35:18 localhost systemd[1]: dev-ttyFIQ0.device: Job dev-ttyFIQ0.device/start failed with result 'timeout'.
Dec 23 13:35:18 localhost systemd[1]: Reached target Login Prompts.
Dec 23 13:35:18 localhost systemd[1]: Reached target Multi-User System.
Dec 23 13:35:18 localhost systemd[1]: Reached target Graphical Interface.
Dec 23 13:35:18 localhost systemd[1]: Starting Update UTMP about System Runlevel Changes...
Dec 23 13:35:18 localhost systemd[1]: systemd-update-utmp-runlevel.service: Succeeded.
Dec 23 13:35:18 localhost systemd[1]: Started Update UTMP about System Runlevel Changes.
Dec 23 13:35:18 localhost systemd[1]: Startup finished in 52.814s (kernel) + 1min 30.570s (userspace) = 2min 23.384s.

 

This is a output of tail -f /var/log/syslog on Linux rockpro64 5.3.11-rockchip64 #19.11.3 SMP PREEMPT Mon Nov 18 21:03:09 CET 2019 aarch64 GNU/Linux so my network dongle is working better now on this kernel after the armbian-config update today 

Share this post


Link to post
Share on other sites

i tried to build the new kernel and by looking throught all the messages i found this:

[ warn ] * [l][c] fix-a64-timejump.patch [ failed ]

 

maybe the patch is there but it is not getting applied properly

Share this post


Link to post
Share on other sites
32 minutes ago, langerma said:

i tried to build the new kernel and by looking throught all the messages i found this

 

Have you updated your build engine sources before? Which kernel?

Share this post


Link to post
Share on other sites
29 minutes ago, langerma said:

i did a git pull beforehand


I checked on my sources and I see no problems on patching (current/dev).

 

Is your head (git log) really this:

commit 246b6726bab48ea67e560cc41c4122ee5fa35d63 (HEAD -> master, origin/master, origin/HEAD)
Merge: b3a68c36 26cf7f2f
Author: count-doku <52237708+count-doku@users.noreply.github.com>
Date:   Sat Dec 28 14:51:02 2019 +0100
I am asking this because I was fixing this patch a week ago.

Share this post


Link to post
Share on other sites

indeed it is:

 

commit 246b6726bab48ea67e560cc41c4122ee5fa35d63
Merge: b3a68c3 26cf7f2
Author: count-doku <52237708+count-doku@users.noreply.github.com>
Date:   Sat Dec 28 14:51:02 2019 +0100

    Merge pull request #1697 from mmriech/fix_dkms

    Fix DKMS in Armbian

Share this post


Link to post
Share on other sites

I just want to confirm that using Armbian 19.11.6 on my pine64 (Linux pine64 5.4.7-sunxi64 #19.11.6 SMP Sat Jan 4 19:40:10 CET 2020 aarch64 GNU/Linux) for a couple of weeks with some workloads (single k3s cluster with some pods running) and 0 issues so far related to the clock.

 

Thanks!

Share this post


Link to post
Share on other sites

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).  Still, I'm OK with that, as long as the clock problem stays gone.

 

Thanks!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
15 hours ago, goathunter said:

went back in time to 1979

The original issue about "massive datetime clock problem" always jump in the future for about 95 years.

So, going "back in time to 1979" must be a different issue ...

Share this post


Link to post
Share on other sites

IIRC, a careful reading of the patch notes indicated that it only actually covered like 99% of cases or something like that, so it is possible (though rare) that it could be the same problem?

Share this post


Link to post
Share on other sites
On 1/31/2020 at 11:06 PM, TRS-80 said:

IIRC, a careful reading of the patch notes indicated that it only actually covered like 99% of cases or something like that, so it is possible (though rare) that it could be the same problem?


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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
11 11