On Thu, Jan 02, 2020 at 04:55:32PM +0500, Mikhail Gavrilov wrote:
> # hwclock -w -v
> hwclock from util-linux 2.35-rc1-20-63f8
> System Time: 1577964536.796672
> Trying to open: /dev/rtc0
> Using the rtc interface to the clock.
> Last drift adjustment done at 1577950892 seconds after 1969
> Last calibration done at 1577950892 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 - 1577964536.797135 is too far past 1577964536.500000
> (0.297135 > 0.001000)
> 1577964537.500000 is close enough to 1577964537.500000 (0.000000 < 0.002000)
> Set RTC to 1577964537 (1577964536 + 1; refsystime = 1577964536.000000)
> Setting Hardware Clock to 11:28:57 = 1577964537 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 1577964536 0.000000
> 1577964536
> UTC
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?
(CC: to [email protected]).
Karel
--
Karel Zak <[email protected]>
http://karelzak.blogspot.com
On Thu, 2 Jan 2020 at 18:14, Karel Zak <[email protected]> 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
--
Best Regards,
Mike Gavrilov.
On Thu, 2 Jan 2020, Mikhail Gavrilov wrote:
> On Thu, 2 Jan 2020 at 18:14, Karel Zak <[email protected]> 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.
>
On Thu, 2 Jan 2020 at 21:59, J William Piggott <[email protected]> wrote:
>
> 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?
>
If you look carefully demonstration the RTC 'reset' happens after
reboot __only__ when 'hwclock -w' have been entered before reboot.
So if I reboot the computer without 'hwclock -w' the RTC will be not reset.
--
Best Regards,
Mike Gavrilov.
Hi,
On 02/01/2020 22:17:26+0500, Mikhail Gavrilov wrote:
> On Thu, 2 Jan 2020 at 21:59, J William Piggott <[email protected]> wrote:
> >
> > 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?
> >
>
> If you look carefully demonstration the RTC 'reset' happens after
> reboot __only__ when 'hwclock -w' have been entered before reboot.
> So if I reboot the computer without 'hwclock -w' the RTC will be not reset.
>
What is your kernel version?
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On Fri, 3 Jan 2020 at 15:02, Alexandre Belloni
<[email protected]> wrote:
>
> Hi,
>
> What is your kernel version?
>
$ uname -r
5.5.0-0.rc4.git0.1.fc32.x86_64
--
Best Regards,
Mike Gavrilov.
On 03/01/2020 15:11:17+0500, Mikhail Gavrilov wrote:
> On Fri, 3 Jan 2020 at 15:02, Alexandre Belloni
> <[email protected]> wrote:
> >
> > Hi,
> >
> > What is your kernel version?
> >
>
> $ uname -r
> 5.5.0-0.rc4.git0.1.fc32.x86_64
>
I'm going to revert 7ad295d5196a58c22abecef62dd4f99e2f86e831, I think
this will solve this issue.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On Fri, 3 Jan 2020 at 15:19, Alexandre Belloni
<[email protected]> 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.
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
> <[email protected]> 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.
>
On Sat, 4 Jan 2020 at 10:46, Jinke Fan <[email protected]> wrote:
>
> Hi Mike,
> The root cause of the bug you encountered is unclear.
>
=== cutted ===
>
> 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.
Did you disable automatic time synchronization?
By default Fedora GNOME doing automatic time synchronization.
For this reason, it’s more correct to immediately go into the BIOS
after a reboot and there check the time value or turn off automatic
time synchronization
--
Best Regards,
Mike Gavrilov.
Hi Mike:
Yes, We do check the time in BIOS Menu after first reboot.
We do some further tests in our X570 platform:
* "AMD Ryzen 7 3700X" with mainboard "ASUS ROG STRIX X570-E GAMING".
* OS is Fedora rawhide, with default Kernel version which is shown as
follows:
$uname -a
Linux bogon 5.5.0-0.rc4.git0.1.fc32.x86_64 #1 SMP Mon Dec 30 06:32:36
UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
And we upgrade/downgrade BIOS version from 1005/1201/1404/1405, and we
found out that :
* OLD BIOS version 1005/1201 does not reset the rtc time and keep the
setup rtc time after reboot.
* NEW BIOS version 1404/1405 DO reset the rtc time to 2019/01/01 after
reboot.
Detailed pictures of the BIOS time after reboot is shown in [2],
We suspect the BIOS 1201->1404 upgrade might cause this issue.
From x570 BIOS changelog [1], we found that the big difference between
1201/1404 is the AMD AM4 PI upgrade from AGESA 1.0.0.3ABBA to AM4 combo
PI 1.0.0.4 patch B,
If possible, please tell us about the BIOS version and your hardware
platform,
which can be get from BIOS UI or using "dmidecode" in Linux env.
Reference:
[1]:
https://www.asus.com/Motherboards/ROG-Strix-X570-E-Gaming/HelpDesk_BIOS/
[2]:https://github.com/fjkbo/rtc
https://raw.githubusercontent.com/fjkbo/rtc/master/1005.jpg
https://raw.githubusercontent.com/fjkbo/rtc/master/1201.jpg
https://raw.githubusercontent.com/fjkbo/rtc/master/1404.jpg
https://raw.githubusercontent.com/fjkbo/rtc/master/1405.jpg
--
Best Regards,
Jinke Fan.
On 2020/1/4 16:25, Mikhail Gavrilov wrote:
> On Sat, 4 Jan 2020 at 10:46, Jinke Fan <[email protected]> wrote:
>>
>> 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.
>
> Did you disable automatic time synchronization?
> By default Fedora GNOME doing automatic time synchronization.
> For this reason, it’s more correct to immediately go into the BIOS
> after a reboot and there check the time value or turn off automatic
> time synchronization
>
> --
> Best Regards,
> Mike Gavrilov.
>
On Sat, 4 Jan 2020 at 16:37, Jinke Fan <[email protected]> wrote:
>
> Hi Mike:
> Yes, We do check the time in BIOS Menu after first reboot.
>
> We do some further tests in our X570 platform:
> * "AMD Ryzen 7 3700X" with mainboard "ASUS ROG STRIX X570-E GAMING".
> * OS is Fedora rawhide, with default Kernel version which is shown as
> follows:
> $uname -a
> Linux bogon 5.5.0-0.rc4.git0.1.fc32.x86_64 #1 SMP Mon Dec 30 06:32:36
> UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
>
> And we upgrade/downgrade BIOS version from 1005/1201/1404/1405, and we
> found out that :
> * OLD BIOS version 1005/1201 does not reset the rtc time and keep the
> setup rtc time after reboot.
> * NEW BIOS version 1404/1405 DO reset the rtc time to 2019/01/01 after
> reboot.
>
> Detailed pictures of the BIOS time after reboot is shown in [2],
>
> We suspect the BIOS 1201->1404 upgrade might cause this issue.
> From x570 BIOS changelog, we found that the big difference between
> 1201/1404 is the AMD AM4 PI upgrade from AGESA 1.0.0.3ABBA to AM4 combo
> PI 1.0.0.4 patch B,
The changelog for my BIOS are the same [1]. Unfortunately, I will not
able downgrade to BIOS of 0404 ver for checking assumption because
changelog description of ver 1404 contains warning "* You will not be
able to downgrade your BIOS after updating to this BIOS version"
> If possible, please tell us about the BIOS version and your hardware
> platform, which can be get from BIOS UI or using "dmidecode"
> in Linux env.
The version of my BIOS is the latest. It is 1405 for my motherboard.
Here is "dmidecode" paste: https://pastebin.com/akBPAvZJ
[1] https://www.asus.com/Motherboards/ROG-Strix-X570-I-Gaming/HelpDesk_BIOS/
--
Best Regards,
Mike Gavrilov.
