Re: [bugreport] "hwclock -w" reset time instead of setting the right time

From: J William Piggott
Date: Thu Jan 02 2020 - 11:59:44 EST




On Thu, 2 Jan 2020, Mikhail Gavrilov wrote:

On Thu, 2 Jan 2020 at 18:14, Karel Zak <kzak@xxxxxxxxxx> wrote:

At first glance it seems hwclock works as expected, I do not see
anything wrong in the output.

Demonstration: https://youtu.be/Yx27IH2opEc

What is hw time before reboot? Can you verify that hwclock reset the
clock? (or is it system reboot?)

# hwclock -w -v
# hwclock -v

Do you see anything interesting in dmesg output before reboot and after
hwclock -w?



Yes, before reboot all look like good:

[root@localhost ~]# hwclock -v
hwclock from util-linux 2.35-rc1-20-63f8
System Time: 1577977370.909455
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1577973311 seconds after 1969
Last calibration done at 1577973311 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2020/01/02 15:02:52
Hw clock time : 2020/01/02 15:02:52 = 1577977372 seconds since 1969
Time since last adjustment is 4061 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2020-01-02 20:02:51.077494+05:00


[root@localhost ~]# hwclock -w -v
hwclock from util-linux 2.35-rc1-20-63f8
System Time: 1577977383.789039
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1577973311 seconds after 1969
Last calibration done at 1577973311 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
RTC type: 'rtc_cmos'
Using delay: 0.500000 seconds
missed it - 1577977383.789405 is too far past 1577977383.500000
(0.289405 > 0.001000)
1577977384.500000 is close enough to 1577977384.500000 (0.000000 < 0.002000)
Set RTC to 1577977384 (1577977383 + 1; refsystime = 1577977383.000000)
Setting Hardware Clock to 15:03:04 = 1577977384 seconds since 1969
ioctl(RTC_SET_TIME) was successful.
Not adjusting drift factor because the --update-drift option was not used.
New /etc/adjtime data:
0.000000 1577977383 0.000000
1577977383
UTC


[root@localhost ~]# hwclock -v
hwclock from util-linux 2.35-rc1-20-63f8
System Time: 1577977389.540630
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1577977383 seconds after 1969
Last calibration done at 1577977383 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2020/01/02 15:03:10
Hw clock time : 2020/01/02 15:03:10 = 1577977390 seconds since 1969
Time since last adjustment is 7 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2020-01-02 20:03:09.718222+05:00

But after reboot, the hwtime is reset:

=== Reboot ===


[root@localhost ~]# hwclock -v
hwclock from util-linux 2.35-rc1-20-63f8
System Time: 1576407103.342223
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1577977383 seconds after 1969
Last calibration done at 1577977383 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2019/01/01 00:05:31
Hw clock time : 2019/01/01 00:05:31 = 1546301131 seconds since 1969
Time since last adjustment is -31676252 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2019-01-01 05:05:30.170661+05:00

[root@localhost ~]# date
Sun 15 Dec 2019 03:52:01 PM +05


Demonstration: https://youtu.be/X0w2hbAmKmM

You've demonstrated that 'hwclock -w' does not 'reset' the RTC.

Does your new motherboard use a battery backup for the RTC?
Is the battery good?



--
Best Regards,
Mike Gavrilov.