Bug 208221 - Clock gets set to the future with linux-5.7.3 and other issues.
Summary: Clock gets set to the future with linux-5.7.3 and other issues.
Status: RESOLVED CODE_FIX
Alias: None
Product: Platform Specific/Hardware
Classification: Unclassified
Component: x86-64 (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: platform_x86_64@kernel-bugs.osdl.org
URL:
Keywords:
: 208223 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-06-17 21:59 UTC by mrtelekinesis
Modified: 2020-06-18 16:13 UTC (History)
5 users (show)

See Also:
Kernel Version: linux-5.7.3
Tree: Mainline
Regression: Yes


Attachments
/proc/cpuinfo output (1.64 KB, text/plain)
2020-06-17 21:59 UTC, mrtelekinesis
Details

Description mrtelekinesis 2020-06-17 21:59:22 UTC
Created attachment 289719 [details]
/proc/cpuinfo output

Upon booting linux-5.7.3, the clock gets set to random times each boot, heres some examples with the command date

Mon Oct 24 15:24:15 EDT 2020
Fri Sep 29 18:32:54 EDT 2020

Other things I notice is that the I/O performance is extremely slow and wpa_supplicant doesn't connect anymore and dhcpcd hangs for a bit on shutdown/reboot, I do not see any error/warning messages in dmesg related to any of this.

with linux-5.7.2 this did not happen at all

I am using a dell latitude D620
I have attached a /proc/cpuinfo output in attachments
Comment 1 menaquinone 2020-06-18 01:54:33 UTC
Confirmed! Thanks for reporting!

On each run the "$ date" command returns a different date, however "$ touch /tmp/a" (where /tmp is ext4 in zram, if it matters) does have the correct date/time when seen by "$ ls -la /tmp/a"

The bootup time is between 19x and 21x (aka times) slower! With 5.7.2 it only takes 10-11 seconds to login prompt, now multiply that with 20 for 5.7.3.

bisect shows:
d7d3023c220d40472adb5789322a91bffb9f6401 is the first bad commit

commit d7d3023c220d40472adb5789322a91bffb9f6401
Date:   Sat Jun 6 23:51:17 2020 +0200
    x86/vdso: Unbreak paravirt VDSO clocks
    commit 7778d8417b74aded842eeb372961cfc460417fa0 upstream.

reverting only this commit on top of 5.7.3 fixes the problems!

maybe someone(OP?) could set  Regression: 	Yes


Have a good day.

PS: I've tested & compiled kernels 5.7.2 and 5.7.3 manually(on ArchLinux/systemd) from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-5.7.y
Comment 2 mrtelekinesis 2020-06-18 05:13:06 UTC
Ok, I set Regression to Yes, thanks for replying.
Comment 3 Thomas Gleixner 2020-06-18 10:03:40 UTC
*** Bug 208223 has been marked as a duplicate of this bug. ***
Comment 4 Thomas Gleixner 2020-06-18 10:05:06 UTC
Can anyone of the reporters please test whether 5.8-rc1 has the same issue?
Comment 5 Thomas Gleixner 2020-06-18 10:21:12 UTC
Already decoded the problem:

  7778d8417b74 ("x86/vdso: Unbreak paravirt VDSO clocks")

depends on:

  72ce778007e5 ("lib/vdso: Provide sanity check for cycles (again)")

72ce778007e5 is marked for stable as well but did not get applied.

With that missing the result is pretty much expexted.

Thanks,

        tglx
Comment 6 gregkh 2020-06-18 12:11:09 UTC
On Thu, Jun 18, 2020 at 10:21:12AM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=208221
> 
> --- Comment #5 from Thomas Gleixner (tglx@linutronix.de) ---
> Already decoded the problem:
> 
>   7778d8417b74 ("x86/vdso: Unbreak paravirt VDSO clocks")
> 
> depends on:
> 
>   72ce778007e5 ("lib/vdso: Provide sanity check for cycles (again)")
> 
> 72ce778007e5 is marked for stable as well but did not get applied.
> 
> With that missing the result is pretty much expexted.

Sorry about that, now queued up for the next stable release.

greg k-h
Comment 7 Thomas Gleixner 2020-06-18 12:56:27 UTC
>> With that missing the result is pretty much expexted.

Should have marked the x86 commit to have a dependency. Next time.

Can the reporters please test linux-5.7.4 ?

Thanks,

        tglx
Comment 8 Reindl Harald 2020-06-18 13:23:07 UTC
yeah, that looks way better

root@test: uname -a
Linux test 5.7.4-rhsoft #1 SMP Thu Jun 18 15:05:17 CEST 2020 x86_64 x86_64 x86_64 GNU/Linux
---------------------------------------------------------
OK: 323, TCP-OPEN: 60, UDP-OPEN: 2, RUNTIME: 42
---------------------------------------------------------
PORTSCAN-TRIGGER:
CALL HONEYPOT: http://172.17.0.98:445: OK: (Status: 1)
CALL ALLOWED: http://172.17.0.6:80: OK: (Status: 1)
CALL TRIGGER: http://172.17.0.6:445: OK: (Status: 0)
CALL CHECK: http://172.17.0.6:80: OK: (Status: 0)
CALL CHECK: http://172.17.0.6:80: OK: (Status: 0)
SLEEP 12 seconds
OK: (http://172.17.0.6:80, Status: 1)
---------------------------------------------------------
CONNLIMIT:
CALL ALLOWED: http://172.17.0.6:80: OK: (Status: 1)
CALL 500 TIMES IN BACKGROUND: http://172.17.0.6:80
CALL: http://172.17.0.6:80: OK: (Status: 0)
---------------------------------------------------------
VPN:

UDP 172.17.0.6:53: 0 OK
UDP 172.16.0.6:53: 1 OK
TCP 172.17.0.6:445: 0 OK
TCP 172.16.0.6:445: 1 OK
---------------------------------------------------------
WIREGUARD:
Thu Jun 18 15:19:00 CEST 2020
Thu Jun 18 15:19:16 CEST 2020
 * 188 Mbits/sec
 * 171 Mbits/sec
Thu Jun 18 15:19:32 CEST 2020
---------------------------------------------------------
NAT:
Thu Jun 18 15:19:32 CEST 2020
Thu Jun 18 15:19:48 CEST 2020
 * 687 Mbits/sec
 * 1.32 Gbits/sec
Thu Jun 18 15:20:04 CEST 2020
---------------------------------------------------------
LAN:
Thu Jun 18 15:20:04 CEST 2020
Thu Jun 18 15:20:20 CEST 2020
 * 4.12 Gbits/sec
 * 5.46 Gbits/sec
Thu Jun 18 15:20:36 CEST 2020
---------------------------------------------------------
Comment 9 menaquinone 2020-06-18 13:25:11 UTC
I can confirm that 5.7.4(which is 5.7.3 plus commit 72ce778007e5 I see) does solve the two problems /aka/ the issue is gone.

Much appreciated!
Keep up the great work all.

Best regards
Comment 10 mrtelekinesis 2020-06-18 16:02:16 UTC
linux-5.7.4 fixes the issues, thanks all.
Comment 11 Borislav Petkov 2020-06-18 16:13:24 UTC
.

Note You need to log in before you can comment on or make changes to this bug.