Hi Alexander,
On Thu, Dec 10, 2020 at 10:02 AM Alexander Bluhm <[email protected]>
wrote:
> On Wed, Dec 09, 2020 at 04:55:09PM -0300, K R wrote:
> > pflog0 logs incorrect timestamp on i386. The machine in question is
> > running under QEMU:
>
> Works for me on a i386 xeon machine.
>
> > hw.vendor=QEMU
>
> hw.machine=i386
> hw.model=Intel(R) Xeon(TM) CPU 3.06GHz ("GenuineIntel" 686-class)
> hw.ncpu=4
> hw.vendor=Supermicro .
> hw.product=X5DL8
>
> > # tcpdump -c 1 -nl -tt -q -i pflog0
> > tcpdump: WARNING: snaplen raised from 116 to 160
> > tcpdump: listening on pflog0, link-type PFLOG
> > 2114522159.012334 51.195.88.92.62841 > xxx.xxx.xxx.xxx.5060: udp 331
>
> root@ot2:.../~# date
> Thu Dec 10 13:48:10 CET 2020
> root@ot2:.../~# tcpdump -c 1 -nl -tt -q -i pflog0
> tcpdump: WARNING: snaplen raised from 116 to 160
> tcpdump: listening on pflog0, link-type PFLOG
> 1607604494.828901 10.188.81.21 > 10.188.81.22: icmp: 8 0
> root@ot2:.../~# date -r 1607604494
> Thu Dec 10 13:48:14 CET 2020
> root@ot2:.../~# date
> Thu Dec 10 13:48:22 CET 2020
>
> So what is the difference between your and my setup?
> I would guess it is a OpenBSD on QEMU timekeeping bug.
>
> Could you run this?
>
> root@ot2:.../~# while sleep 1; do date; done
> Thu Dec 10 13:56:47 CET 2020
> Thu Dec 10 13:56:48 CET 2020
> Thu Dec 10 13:56:49 CET 2020
> Thu Dec 10 13:56:50 CET 2020
>
> Does it print one line per second? Does the date output increment
> by one second? Use an independent clock to watch it. Then we see
> if timeouts, clock and real world are in sync.
>
>
It seems ok...
server# while sleep 1; do date; done
Sat Dec 12 22:16:32 GMT 2020
Sat Dec 12 22:16:33 GMT 2020
Sat Dec 12 22:16:34 GMT 2020
Sat Dec 12 22:16:35 GMT 2020
Sat Dec 12 22:16:36 GMT 2020
Sat Dec 12 22:16:37 GMT 2020
^C
> What does sysctl kern.timecounter say?
>
>
server# sysctl kern.timecounter
kern.timecounter.tick=1
kern.timecounter.timestepwarnings=0
kern.timecounter.hardware=pvclock0
kern.timecounter.choice=i8254(0) pvclock0(1500) acpitimer0(1000)
Please let me know if you need more testing. Thanks for looking into this.
--Kor
>
> bluhm
