FS#27408 - [linux] rtc is not corrected if more than 15 minutes off
Attached to Project:
Arch Linux
Opened by Dan McGee (toofishes) - Friday, 02 December 2011, 15:49 GMT
Last edited by Tobias Powalowski (tpowa) - Tuesday, 30 July 2013, 10:44 GMT
Opened by Dan McGee (toofishes) - Friday, 02 December 2011, 15:49 GMT
Last edited by Tobias Powalowski (tpowa) - Tuesday, 30 July 2013, 10:44 GMT
|
Details
Every time I boot my home computer, the clock is off by an
hour.
We need to sync the hwclock on shutdown, no ifs/ands/buts, if we are using it on startup. ntpd does not sync this, ever, contrary to what the bogus comment implies in rc.conf. |
This task depends upon
Would you care to explain a bit more why you think the comment is bogus? Have you verified that 11-minute-mode is not enabled in your kernel when ntp is running? If it is not, what makes you think this is not a bug (a link to discussion/documentation would be great)?
We should never set rtc from system time, unless we are certain that system time is correct. There are two ways the rtc could be set: manually by calling hwclock if you happen to know what time it is; or let the kernel know that system time is correct and it will make sure to update the rtc from time to time (11-minutes-mode).
When using an ntp server the latter is done. This can be verified by checking the kernel's time status bit 0x40 / STA_UNSYNC, which should be unset if an ntp server is being used. As far as I know this works well with ntpd.
There is a caveat here, the kernel will never update the rtc if it is more than 30 minutes wrong. This might have made sense when we still cared about working around rtc being in localtime, but nowadays it does not make any sense at all.
To fix this issue ntpd should either be made to set rtc by force, or the kernel should be patched to ignore the 30-min limit.
A workaround should be (please confirm) to set rtc manually using hwclock (to something which is less than 30 minutes wrong) and then wait for the 11-minutes-mode to kick in and set the proper time.
The final workaround seems to work- I haven't seen a mismatched local call since I explicitly called hwclock and set the time. Does this get confused by localtime/UTC or what is the status with that?
The kernel's rtc handling has no clue about localtime (as far as I can tell), so there is no way this could work seamlessly with RTC in localtime.
The way it works now is that if your RTC is in localtime the kernel will never touch it (I guess the 30-min limit is meant as a test for RTC being in localtime). The assumption being that a secondary OS is in use which will take care of the clock.
We have sort of given up on supporting localtime, but we try to at least stay out of the way if the user wants to use it (it should work fine if you are willing and able to adjust the clock manually from time to time).
Apart from that, I'd still like to point out that using localtime is broken by design.
I hope it will be posted to LKML, I'll keep an eye on it.