Hi Mike, The root cause of the bug you encountered is unclear. I also tested it at "AMD Ryzen 7 3700X" with mainboard "ASUS ROG STRIX X570-E GAMING". kernel version are linus 5.5.0-rc4 and fedora 5.5.0-0.rc4.git0.1.fc32.x86_64. [root@bogon ]# hwclock -v hwclock from util-linux 2.35-rc1-20-63f8 System Time: 1578110670.568539 Trying to open: /dev/rtc0 Using the rtc interface to the clock. Last drift adjustment done at 0 seconds after 1969 Last calibration done at 0 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/04 04:04:31 Hw clock time : 2020/01/04 04:04:31 = 1578110671 seconds since 1969 Time since last adjustment is 1578110671 seconds Calculated Hardware Clock drift is 0.000000 seconds 2020-01-04 12:04:30.764426+08:00 [root@bogon ]# [root@bogon ]# hwclock -w -v hwclock from util-linux 2.35-rc1-20-63f8 System Time: 1578110696.999848 Trying to open: /dev/rtc0 Using the rtc interface to the clock. Last drift adjustment done at 0 seconds after 1969 Last calibration done at 0 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 1578110697.500000 is close enough to 1578110697.500000 (0.000000 < 0.001000) Set RTC to 1578110697 (1578110697 + 0; refsystime = 1578110697.000000) Setting Hardware Clock to 04:04:57 = 1578110697 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 1578110697 0.000000 1578110697 UTC [root@bogon ]# hwclock -v hwclock from util-linux 2.35-rc1-20-63f8 System Time: 1578110720.716094 Trying to open: /dev/rtc0 Using the rtc interface to the clock. Last drift adjustment done at 1578110697 seconds after 1969 Last calibration done at 1578110697 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/04 04:05:21 Hw clock time : 2020/01/04 04:05:21 = 1578110721 seconds since 1969 Time since last adjustment is 24 seconds Calculated Hardware Clock drift is 0.000000 seconds 2020-01-04 12:05:20.920803+08:00 [root@bogon ]# [root@bogon ]# reboot [root@bogon ]# hwclock -v hwclock from util-linux 2.35-rc1-20-63f8 System Time: 1578110959.144472 Trying to open: /dev/rtc0 Using the rtc interface to the clock. Last drift adjustment done at 1578110697 seconds after 1969 Last calibration done at 1578110697 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/04 04:09:20 Hw clock time : 2020/01/04 04:09:20 = 1578110960 seconds since 1969 Time since last adjustment is 263 seconds Calculated Hardware Clock drift is 0.000000 seconds 2020-01-04 12:09:19.358191+08:00 [root@bogon ]# dmesg |grep -i rtc [ 0.127226] PM: RTC time: 04:06:59, date: 2020-01-04 [ 1.546411] rtc_cmos 00:03: RTC can wake from S4 [ 1.546532] rtc_cmos 00:03: registered as rtc0 [ 1.546533] rtc_cmos 00:03: alarms up to one month, y3k, 114 bytes nvram, hpet irqs [ 1.589157] rtc_cmos 00:03: setting system clock to 2020-01-04T04:07:01 UTC (1578110821) [root@bogon ]# There is no date reset found in the bios after reboot. The first time during OS startup get date from rtc_cmos is: [ 1.589157] rtc_cmos 00:03: setting system clock to 2020-01-04T04:07:01 UTC (1578110821) I watched the video on youtube. The date is reseted when startup into bios at Mike's platform. As we know that the bios will check the validity of rtc time, if not, bios will reset the rtc time. RTC time reset may be done by the BIOS. Whatever I'm so sorry for the issue. Best regards. Jinke Fan On 2020/1/3 22:22, Mikhail Gavrilov wrote: > On Fri, 3 Jan 2020 at 15:19, Alexandre Belloni > <alexandre.belloni@xxxxxxxxxxx> wrote: >> I'm going to revert 7ad295d5196a58c22abecef62dd4f99e2f86e831, I think >> this will solve this issue. >> > > Just checked kernel with reverted commit > 7ad295d5196a58c22abecef62dd4f99e2f86e831, > and I can confirm that any time could be successfully set via 'hwclock -w'. > Thanks, waiting for the patch in master. > > -- > Best Regards, > Mike Gavrilov. >
