Hide Forgot
Description of problem: After reboot of computer time isn't set correctly. Version-Release number of selected component (if applicable): systemd-37-3.fc16.x86_64 chrony-1.26-3.20110831gitb088b7.fc16.x86_64 How reproducible: After every reboot. Steps to Reproduce: 1. time is correct, set by chronyd for my time zone 2. switch off computer in 9:58 3. switch on with(out) network 4. time is set to 18:59 Actual results: Without network synchronization is time set to wrong time. I didn't find explanation. Could it be that I see time, which is set by last call of "hwclock --systohc"? Expected results: Correct time, everytime. Additional info: This is not bug of chronyd, because it "fixes" the time value. I wonder what people without network will do.
(In reply to comment #0) > Could it be that I see time, which is set by last call of > "hwclock --systohc"? I don't know. Does running that command change what you're seeing?
(In reply to comment #1) > (In reply to comment #0) > > Could it be that I see time, which is set by last call of > > "hwclock --systohc"? > > I don't know. Does running that command change what you're seeing? No, it's not related to when I run hwclock.
When ntp is used, the kernel writes the current time to to the RTC every 11 minutes, but it only corrects for errors within a 30-minute window. It won't fix the hours. That may explain what you're seeing. But if it's really it, I'd expect that "hwclock --systohc" run before shutdown to result in the correct time after new boot.
Michal, do you know which kernel code does the minutes-update-only? I can't find that limitation in the code. We should decide what to fix here, if we optionally let the kernel do a full sync instead of minutes only, or ask the ntp implementations to solve that for us. But first I need to find the code in the kernel, that does that. :)
It's mach_set_rtc_mmss() in arch/x86/kernel/rtc.c
Merging with #816752 which is the same issue. This one is older, but the other one has more information, and the discussion took place in the other bug. Thanks! *** This bug has been marked as a duplicate of bug 816752 ***