Hi,
On 2022-05-13 10:22:32 -0700, Andres Freund wrote:
> On 2022-05-13 09:00:20 +0200, Mikael Kjellström wrote:
> > Well, I don't know if you remember but there was a thread a while back and a
> > test program (monotime.c) to test the clock if it could go backwards and
> > openbsd showed the following result when running the attached testprogram:
>
> Nope, didn't remember...
>
>
> > $ ./monotime
> > 410310 Starting
> > 547727 Starting
> > 410310 Back 262032.372314102 => 262032.242045208
> > 410310 Stopped
> > 465180 Starting
> > 255646 Starting
> > 547727 Stopped
> > 465180 Stopped
> > 255646 Stopped
> >
> > could that have something to do with it?
>
> Yes!
>
>
> > printf("%d Back %lld.%09lu => %lld.%09lu\n",
> > (int)getthrid(), ts0.tv_sec, ts0.tv_nsec, ts1.tv_sec,
> > ts1.tv_nsec);
> > break;
>
> I wonder whether the %09lu potentially is truncating ts1.tv_nsec.
>
>
> I can't reproduce the problem trivially in an openbsd VM I had around. But
> it's 7.1, so maybe that's the reason?
What does
sysctl kern.timecounter
return? Does the problem continue if you switch kern.timecounter.hardware to
something else?
In https://postgr.es/m/32aaeb66-71b2-4af0-91ef-1a992ac4d58b%40mksoft.nu you
said it was using acpitimer0 and that it's a vmware VM. It might also be a
vmware bug, not an openbsd one...
Greetings,
Andres Freund