On 2022-05-13 22:09, Andres Freund wrote:
> What does
> sysctl kern.timecounter
> return? Does the problem continue if you switch kern.timecounter.hardware to
> something else?
openbsd 5.9:
$ sysctl kern.timecounter
kern.timecounter.tick=1
kern.timecounter.timestepwarnings=0
kern.timecounter.hardware=acpihpet0
kern.timecounter.choice=i8254(0) acpihpet0(1000) acpitimer0(1000)
dummy(-1000000)
$ ./monotime
1024736 Starting
1013674 Starting
1028468 Starting
1014641 Starting
1013674 Stopped
1024736 Stopped
1014641 Stopped
1028468 Stopped
no problem
openbsd 6.9:
$ sysctl kern.timecounter
kern.timecounter.tick=1
kern.timecounter.timestepwarnings=0
kern.timecounter.hardware=tsc
kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000) acpitimer0(1000)
Hm, here it's using the tsc timer. So that is a difference from 5.9
$ ./monotime
133998 Starting
408137 Starting
578042 Starting
326139 Starting
133998 Back 310670.000931851668 => 310670.000801582864
133998 Stopped
326139 Stopped
578042 Stopped
408137 Stopped
it's only in 6.9 the problem with the timer going backwards shows up.
If I switch timer to acpihpet0 this is the result:
$ ./monotime
101622 Starting
480782 Starting
219318 Starting
316650 Starting
101622 Stopped
480782 Stopped
219318 Stopped
316650 Stopped
so that seems to solve the problem with the timer going backwards.
> 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...
Might be a bug in vmware but it's running the latest patchlevel for 6.7
and no other VM have this problem so seems to only happen in openbsd 6.9
for some reason. Maybe that is the only VM that is using tsc as a timer
source though?
/Mikael