[bugreport] Ext4 automatically checked at each boot

[bugreport] Ext4 automatically checked at each boot

[Mikhail Gavrilov]

Hi folks.

Strange things happen with my ext4 lately:
- At each boot, the file system is checked.
- When I launch fsck manually it didn't found any issue.
- But tune2fs report that last checked and mount time is Sun Dec 15,
but this is incorrect.

I don’t know where to look further so I ask here for help.


Here is tune2fs report: https://pastebin.com/PZPbAuHS

# cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Mon Sep  9 19:36:53 2019
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
UUID=b3e2e027-c39d-4266-871f-22d313ac419b /                       ext4
   defaults        1 1
UUID=E8A2-F389          /boot/efi               vfat
umask=0077,shortname=winnt 0 2
UUID=bf3e9504-8000-42a1-adb4-226658ec7a5d /home                   ext4
   defaults        1 2
UUID=f47f69e1-61f8-4024-960a-b3981d3b1d02 none                    swap
   defaults        0 0


--
Best Regards,
Mike Gavrilov.

Re: [bugreport] Ext4 automatically checked at each boot

[Mikhail Gavrilov]

Maybe important:
This start happens since I upgraded motherboard to "ROG Strix X570-I
Gaming" on my previous motherboard "ROG STRIX X470-I GAMING" the
values "last checked", "mount time",  "mount count" was correctly
updated and displayed. And auto-check not started each boot.

On Wed, 1 Jan 2020 at 15:58, Mikhail Gavrilov
<mikhail.v.gavrilov@gmail.com> wrote:
>
> Hi folks.
>
> Strange things happen with my ext4 lately:
> - At each boot, the file system is checked.
> - When I launch fsck manually it didn't found any issue.
> - But tune2fs report that last checked and mount time is Sun Dec 15,
> but this is incorrect.
>
> I don’t know where to look further so I ask here for help.
>
>
> Here is tune2fs report: https://pastebin.com/PZPbAuHS
>
> # cat /etc/fstab
>
> #
> # /etc/fstab
> # Created by anaconda on Mon Sep  9 19:36:53 2019
> #
> # Accessible filesystems, by reference, are maintained under '/dev/disk/'.
> # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
> #
> # After editing this file, run 'systemctl daemon-reload' to update systemd
> # units generated from this file.
> #
> UUID=b3e2e027-c39d-4266-871f-22d313ac419b /                       ext4
>    defaults        1 1
> UUID=E8A2-F389          /boot/efi               vfat
> umask=0077,shortname=winnt 0 2
> UUID=bf3e9504-8000-42a1-adb4-226658ec7a5d /home                   ext4
>    defaults        1 2
> UUID=f47f69e1-61f8-4024-960a-b3981d3b1d02 none                    swap
>    defaults        0 0
>
>
> --
> Best Regards,
> Mike Gavrilov.

Re: [bugreport] Ext4 automatically checked at each boot

[Theodore Y. Ts'o]

On Wed, Jan 01, 2020 at 03:58:25PM +0500, Mikhail Gavrilov wrote:
> Hi folks.
> 
> Strange things happen with my ext4 lately:
> - At each boot, the file system is checked.
> - When I launch fsck manually it didn't found any issue.
> - But tune2fs report that last checked and mount time is Sun Dec 15,
> but this is incorrect.

The problem is casued by the fact that the mount time is incorrect,
which indicates that the system time was incorrect at the time when
the file system was mounted and when it fsck was run.  Since the last
write time was in the future, this triggered "time is insane" check.

This is inconsistent with your report that started happening when you
switched to a new motherboard.  That's because the real time clock is
not reporting the correct time when the system is booted.  Later on,
in the boot cycle, after the root file system is checked and remounted
read-write, the system time is getting set from an internet time
server.  This then causes the last write time to be ahead of the last
mount time, and "in the future" with respect to the real time clock.

Normally, the hardware clock's time gets set to match system time when
it is set from network time, or when the system is getting shut down
cleanly, but your init scripts aren't doing this properly --- or you
normally shut down your system by just flipping the power switch, and
not letting the shutdown sequence run correctly.  The other possibilty
is the real time clock on your system is just completly busted
(although normally when that happens, the last mount time would be in
the 1970's.)

Running "/sbin/hwclock -w" as root may fix things; as is figuring out
why this isn't run automatically by your boot scripts.  Another
workaround is to add to /etc/e2fsck.conf the following:

[options]
	broken_system_lock = true

This will disable e2fsck's time checks.

Cheers,

					- Ted

Re: [bugreport] Ext4 automatically checked at each boot

[Mikhail Gavrilov]

On Wed, 1 Jan 2020 at 19:17, Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> The problem is casued by the fact that the mount time is incorrect,
> which indicates that the system time was incorrect at the time when
> the file system was mounted and when it fsck was run.  Since the last
> write time was in the future, this triggered "time is insane" check.
>
> This is inconsistent with your report that started happening when you
> switched to a new motherboard.  That's because the real time clock is
> not reporting the correct time when the system is booted.  Later on,
> in the boot cycle, after the root file system is checked and remounted
> read-write, the system time is getting set from an internet time
> server.  This then causes the last write time to be ahead of the last
> mount time, and "in the future" with respect to the real time clock.
>
> Normally, the hardware clock's time gets set to match system time when
> it is set from network time, or when the system is getting shut down
> cleanly, but your init scripts aren't doing this properly --- or you
> normally shut down your system by just flipping the power switch, and
> not letting the shutdown sequence run correctly.  The other possibilty
> is the real time clock on your system is just completly busted
> (although normally when that happens, the last mount time would be in
> the 1970's.)
>
> Running "/sbin/hwclock -w" as root may fix things; as is figuring out
> why this isn't run automatically by your boot scripts.  Another
> workaround is to add to /etc/e2fsck.conf the following:
>
> [options]
>         broken_system_lock = true
>
> This will disable e2fsck's time checks.
>

Thank you very much for the tip, I would never have guessed that the
cause of this issue in hwclock.
I started to watch hwclock through the motherboard BIOS and found that
hwclock resets every time after booting Linux.
Demonstration: https://youtu.be/TBrLNFbBaPo
Apparently for this reason, "hwclock -w" did not help me, workaround
with "broken_system_clock = true" is working, but I would like to fix
the root of the cause.
Who can help with this?


--
Best Regards,
Mike Gavrilov.

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

[Mikhail Gavrilov]

"hwclock -w" reset time instead of setting the right time on M/B "ROG
Strix X570-I Gaming"
Demonstration: https://youtu.be/QRB7ZLiEfrc
Some DE like GNOME has automatic time synchronization option and there
is a feeling that hardware time reset after each Linux boot.

--
Best Regards,
Mike Gavrilov.
On Thu, 2 Jan 2020 at 04:19, Mikhail Gavrilov
<mikhail.v.gavrilov@gmail.com> wrote:
>
> On Wed, 1 Jan 2020 at 19:17, Theodore Y. Ts'o <tytso@mit.edu> wrote:
> >
> > The problem is casued by the fact that the mount time is incorrect,
> > which indicates that the system time was incorrect at the time when
> > the file system was mounted and when it fsck was run.  Since the last
> > write time was in the future, this triggered "time is insane" check.
> >
> > This is inconsistent with your report that started happening when you
> > switched to a new motherboard.  That's because the real time clock is
> > not reporting the correct time when the system is booted.  Later on,
> > in the boot cycle, after the root file system is checked and remounted
> > read-write, the system time is getting set from an internet time
> > server.  This then causes the last write time to be ahead of the last
> > mount time, and "in the future" with respect to the real time clock.
> >
> > Normally, the hardware clock's time gets set to match system time when
> > it is set from network time, or when the system is getting shut down
> > cleanly, but your init scripts aren't doing this properly --- or you
> > normally shut down your system by just flipping the power switch, and
> > not letting the shutdown sequence run correctly.  The other possibilty
> > is the real time clock on your system is just completly busted
> > (although normally when that happens, the last mount time would be in
> > the 1970's.)
> >
> > Running "/sbin/hwclock -w" as root may fix things; as is figuring out
> > why this isn't run automatically by your boot scripts.  Another
> > workaround is to add to /etc/e2fsck.conf the following:
> >
> > [options]
> >         broken_system_lock = true
> >
> > This will disable e2fsck's time checks.
> >
>
> Thank you very much for the tip, I would never have guessed that the
> cause of this issue in hwclock.
> I started to watch hwclock through the motherboard BIOS and found that
> hwclock resets every time after booting Linux.
> Demonstration: https://youtu.be/TBrLNFbBaPo
> Apparently for this reason, "hwclock -w" did not help me, workaround
> with "broken_system_clock = true" is working, but I would like to fix
> the root of the cause.
> Who can help with this?
>

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

[Karel Zak]

On Thu, Jan 02, 2020 at 01:08:41PM +0500, Mikhail Gavrilov wrote:
> "hwclock -w" reset time instead of setting the right time on M/B "ROG
> Strix X570-I Gaming"
> Demonstration: https://youtu.be/QRB7ZLiEfrc
> Some DE like GNOME has automatic time synchronization option and there
> is a feeling that hardware time reset after each Linux boot.

 Can you try "hwclock -w -v" to get more details?

 For example on my workstation:

        # ./hwclock -w -v
        hwclock from util-linux 2.35-rc1-20-63f8
        System Time: 1577963091.683987
        Trying to open: /dev/rtc0
        Using the rtc interface to the clock.
        Last drift adjustment done at 1531914946 seconds after 1969
        Last calibration done at 1531914946 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 - 1577963091.684767 is too far past 1577963091.500000 (0.184767 > 0.001000)
        1577963092.500000 is close enough to 1577963092.500000 (0.000000 < 0.002000)
        Set RTC to 1577963092 (1577963091 + 1; refsystime = 1577963091.000000)
        Setting Hardware Clock to 11:04:52 = 1577963092 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 1577963091 0.000000
        1577963091
        UTC


    Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

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

[Mikhail Gavrilov]

On Thu, 2 Jan 2020 at 16:08, Karel Zak <kzak@redhat.com> wrote:
>
>  Can you try "hwclock -w -v" to get more details?
>
>  For example on my workstation:
>
>         # ./hwclock -w -v
>         hwclock from util-linux 2.35-rc1-20-63f8
>         System Time: 1577963091.683987
>         Trying to open: /dev/rtc0
>         Using the rtc interface to the clock.
>         Last drift adjustment done at 1531914946 seconds after 1969
>         Last calibration done at 1531914946 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 - 1577963091.684767 is too far past 1577963091.500000 (0.184767 > 0.001000)
>         1577963092.500000 is close enough to 1577963092.500000 (0.000000 < 0.002000)
>         Set RTC to 1577963092 (1577963091 + 1; refsystime = 1577963091.000000)
>         Setting Hardware Clock to 11:04:52 = 1577963092 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 1577963091 0.000000
>         1577963091
>         UTC
>

# 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

Demonstration: https://youtu.be/Yx27IH2opEc

--
Best Regards,
Mike Gavrilov.

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

[Karel Zak]

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 linux-rtc@vger.kernel.org).

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

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

[Mikhail Gavrilov]

On Thu, 2 Jan 2020 at 18:14, Karel Zak <kzak@redhat.com> 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.

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

[J William Piggott]

On Thu, 2 Jan 2020, Mikhail Gavrilov wrote:

> On Thu, 2 Jan 2020 at 18:14, Karel Zak <kzak@redhat.com> 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.
>

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

[Mikhail Gavrilov]

On Thu, 2 Jan 2020 at 21:59, J William Piggott <elseifthen@gmx.com> 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.

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

[Alexandre Belloni]

Hi,

On 02/01/2020 22:17:26+0500, Mikhail Gavrilov wrote:
> On Thu, 2 Jan 2020 at 21:59, J William Piggott <elseifthen@gmx.com> 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

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

[Mikhail Gavrilov]

On Fri, 3 Jan 2020 at 15:02, Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
>
> Hi,
>
> What is your kernel version?
>

$ uname -r
5.5.0-0.rc4.git0.1.fc32.x86_64


--
Best Regards,
Mike Gavrilov.

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

[Alexandre Belloni]

On 03/01/2020 15:11:17+0500, Mikhail Gavrilov wrote:
> On Fri, 3 Jan 2020 at 15:02, Alexandre Belloni
> <alexandre.belloni@bootlin.com> 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

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

[Mikhail Gavrilov]

On Fri, 3 Jan 2020 at 15:19, Alexandre Belloni
<alexandre.belloni@bootlin.com> 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.

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

[Jinke Fan]

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@bootlin.com> 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.
> 

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

[Mikhail Gavrilov]

On Sat, 4 Jan 2020 at 10:46, Jinke Fan <fanjinke@hygon.cn> 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.

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

[Jinke Fan]

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 <fanjinke@hygon.cn> 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.
> 

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

[Mikhail Gavrilov]

On Sat, 4 Jan 2020 at 16:37, Jinke Fan <fanjinke@hygon.cn> 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.