On Thu, Jun 4, 2020 at 7:30 PM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > > Miklos, > > Thomas Gleixner <tglx@xxxxxxxxxxxxx> writes: > >> Of course this does not reproduce here. What kind of host is this > >> running on? Can you provide a full demsg of the host please from boot to > >> post resume? > > > > Plus /proc/cpuinfo please (one CPU is sufficient) > > thanks for providing the data. Unfortunately not really helpful. The > host has a non-stop TSC and the dmesg does not contain anything which > sheds light on this. > > I grabbed a similar machine, installed a guest with 5.7 kernel and I'm > still unable to reproduce. No idea yet how to get down to the real root > cause of this. Well, I have neither. But more investigation turned up some interesting things. time(2) returns good time, while clock_gettime(2) returns bad time. Here's an example: time=1591298725 RT=1591300383 MONO=39582 MONO_RAW=39582 BOOT=39582 time=1591298726 RT=1591300383 MONO=39582 MONO_RAW=39582 BOOT=39582 time=1591298727 RT=1591300383 MONO=39582 MONO_RAW=39582 BOOT=39582 time=1591298728 RT=1591300383 MONO=39582 MONO_RAW=39582 BOOT=39582 time=1591298729 RT=1591300383 MONO=39582 MONO_RAW=39582 BOOT=39582 As you can see, only time(2) is updated, the others remain the same. date(1) uses clock_gettime(CLOCK_REALTIME) so that shows the bad date. When the correct time reaches the value returned by CLOCK_REALTIME, the value jumps exactly 2199 seconds. Does that make any sense? Thanks, Miklos
