On Fri, Jun 5, 2020 at 12:12 PM Thomas Gleixner wrote:
>
> Paolo Bonzini writes:
> > On 04/06/20 21:28, Miklos Szeredi wrote:
> >> 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
Paolo Bonzini writes:
> On 04/06/20 21:28, Miklos Szeredi wrote:
>> 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
On 05/06/20 09:35, Miklos Szeredi wrote:
>> time(2) instead should actually be gettimeofday(2), which just returns
>> tk->xtime_sec. So the problem is the nanosecond part which is off by
>> 2199*10^9 nanoseconds, and that is suspiciously close to 2^31...
> Yep: looking at the nanosecond values as
On Thu, Jun 4, 2020 at 10:14 PM Paolo Bonzini wrote:
>
> On 04/06/20 21:28, Miklos Szeredi wrote:
> > 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
On 04/06/20 21:28, Miklos Szeredi wrote:
> 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
On Thu, Jun 4, 2020 at 7:30 PM Thomas Gleixner wrote:
>
> Miklos,
>
> Thomas Gleixner 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
Miklos,
Thomas Gleixner 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
Thomas Gleixner writes:
> Miklos Szeredi writes:
>> On Fri, May 29, 2020 at 2:31 PM Miklos Szeredi wrote:
>>
>>> > Can you please describe the setup of this test?
>>> >
>>> > - Host kernel version
>>
>> 5.5.16-100.fc30.x86_64
>>
>>> > - Guest kernel version
>>
>> 75caf310d16c ("Merge branch
Miklos Szeredi writes:
> On Fri, May 29, 2020 at 2:31 PM Miklos Szeredi wrote:
>
>> > Can you please describe the setup of this test?
>> >
>> > - Host kernel version
>
> 5.5.16-100.fc30.x86_64
>
>> > - Guest kernel version
>
> 75caf310d16c ("Merge branch 'akpm' (patches from Andrew)")
>
>> >
On Fri, May 29, 2020 at 2:31 PM Miklos Szeredi wrote:
> > Can you please describe the setup of this test?
> >
> > - Host kernel version
5.5.16-100.fc30.x86_64
> > - Guest kernel version
75caf310d16c ("Merge branch 'akpm' (patches from Andrew)")
> > - Is the revert done on the host or
On Fri, May 29, 2020 at 2:21 PM Thomas Gleixner wrote:
>
> Miklos,
>
> Miklos Szeredi writes:
> > On Fri, May 29, 2020 at 11:51 AM Miklos Szeredi wrote:
> >> On Thu, May 28, 2020 at 10:43 PM Thomas Gleixner
> >> wrote:
> >> >
> >> > Miklos Szeredi writes:
> >> > > Bisected it to:
> >> > >
>
Miklos,
Miklos Szeredi writes:
> On Fri, May 29, 2020 at 11:51 AM Miklos Szeredi wrote:
>> On Thu, May 28, 2020 at 10:43 PM Thomas Gleixner wrote:
>> >
>> > Miklos Szeredi writes:
>> > > Bisected it to:
>> > >
>> > > b95a8a27c300 ("x86/vdso: Use generic VDSO clock mode storage")
>> > >
>> > >
On Fri, May 29, 2020 at 11:51 AM Miklos Szeredi wrote:
>
> On Thu, May 28, 2020 at 10:43 PM Thomas Gleixner wrote:
> >
> > Miklos Szeredi writes:
> > > Bisected it to:
> > >
> > > b95a8a27c300 ("x86/vdso: Use generic VDSO clock mode storage")
> > >
> > > The effect observed is that after the
On Thu, May 28, 2020 at 10:43 PM Thomas Gleixner wrote:
>
> Miklos Szeredi writes:
> > Bisected it to:
> >
> > b95a8a27c300 ("x86/vdso: Use generic VDSO clock mode storage")
> >
> > The effect observed is that after the host is resumed, the clock in
> > the guest is somewhat in the future and is
Miklos Szeredi writes:
> Bisected it to:
>
> b95a8a27c300 ("x86/vdso: Use generic VDSO clock mode storage")
>
> The effect observed is that after the host is resumed, the clock in
> the guest is somewhat in the future and is stopped. I.e. repeated
> date(1) invocations show the same time.
TBH,
Bisected it to:
b95a8a27c300 ("x86/vdso: Use generic VDSO clock mode storage")
The effect observed is that after the host is resumed, the clock in
the guest is somewhat in the future and is stopped. I.e. repeated
date(1) invocations show the same time.
Attaching the .config
Thanks,
Miklos
16 matches
Mail list logo
