|Re: [chrony-users] Chrony malfunction under ARM/Buildroot|
[ Thread Index |
| More chrony.tuxfamily.org/chrony-users Archives
Thanks a lot,
Il 14/04/2016 23:03, Bill Unruh ha scritto:
With no rtc ( which is a hardware problem not a chrony problem) there is no
way the system can know what the time is or how to make sure everything is
always monotonic. You will just have to make sure that the problem never
AFAIK chrony (I start it as: "chronyd -r -s") should look for the "driftfile" (present in my system) and set the time&date from it; this does not seem to happen.
That is a driftfile for the rtc. If the rtc is way way out, it has nothing to
fix-- ie the fix is nonesense. If your rtc is as flaky as you imply, it might
be better not to use the rtc at all. AFAI remember, if there is not rtc (ie
the rtcfile directive) chrony will look at a few files, and use the dates from
them to set the current time. That will be out (depending on how long th
emachine has been off) but it will be in the past, so your concern about the
system always going forward will be satisfied.
If I understand well the "-s" option forces chrony to restart timing from the date of the "driftfile" file (thus providing a monotone, even if wrong, time).
Did misinterpret the manual?
As said this seems linked to chrony as neither condition happens if chrony is not running.
Yes, but it still might not be chrony. On the other hand the log file you
showed suggests that it is the rtc that is causing trouble. (Is it HPET? or
what is the rtc on your system).
My current work hypothesis is something bad happens when chronyd tries to update RTC.
I want to verify this updating RTC with different means (ntpdate).
It might not be conclusive, but will give me some hint (hopefully).
I will try substituting nntp/ntpdate in order to see if the problem is in touching time (i.e.: it is in the kernel itself).
The logs suggest that it is a problem with the rtc. You might well be better
off not using the rtc at all. Is it a separate card?
The RTC is internal to the MCU itself, only the quartz oscillator is external (and that should be OK, because it clocks also other peripherals).
There is a separate power line feeding this part even when the rest of the board is powered off.
A complete reset happens when the Power supply *and* the backup battery are disconnected at the same time.
The strange date&time I get is the value the RTC registers get when completely unprogrammed (i.e.: when the above condition is verified), so that part is "normal".
RTC is internal to MCU, so it might be misprogrammed, but I strongly doubt there is a real hardware issue, also because I see this problem in multiple boards.
I will cross-check initializations in both bootloader and .dts
If You have specific suggestion please feel free to advise.
I think I have reached the limits of my competence.
Any other taker?
If something comes to mind... ;)
and Thanks again.
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.