On Tue, Dec 26, 2017 at 03:24:03PM -0500, Andrew Davis wrote: > Hello, > > No, I didn't changing the kern.timecounter selection directly. I had tried > disabling the HPET on qemu/kvm (which may have affected this selection?). > > Two of my boxes, both OpenBSD 6.1 report this: > > # 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) > > Best, > Andrew >
Could you try one of the others and let us know if it helps, please? -ml > On 12/26/2017 2:36 PM, Mike Larkin wrote: > > On Tue, Dec 26, 2017 at 12:27:31PM -0500, Andrew Davis wrote: > > > Hello, > > > > > > I'm experiencing some odd timing issues on OpenBSD 6.2 (and 6.1) on the > > > system listed below. This is preventing me from running OpenBSD on my > > > servers. Can you determine if this is a bug in the OpenBSD operating > > > system? > > > I can provide more information if needed. > > > > > > Virtualized environment. > > > > > > Host CPU: 2 x Intel E5-2630 v3 2.4 Ghz > > > Host OS: Fedora 27 > > > Virtualization software: QEMU + KVM (2.10.0-1.fc27) > > > Guest Machine: default (pc-i440fx-2.10) > > > Guest OS: OpenBSD 6.2 (and 6.1). > > > > > > Basically, OpenBSD processes degrade over time to the point where they're > > > completely unresponsive. This simple date printout script is a good > > > example. > > > It should print out the date once per second, but after roughly ~20 mins > > > on > > > this hardware configuration, it takes 2 seconds to print each line, then 4 > > > seconds to print each line, and so on. After running for about 24 hours, > > > the > > > delay is about 1 minute between line printouts. > > > > > > while sleep 1; do date; done > > > > > > I've tried tweaking some different settings on the guest and host, such as > > > disabling the HPET timer and x2apic, neither of which has proven > > > effective. > > > > > > I saw mention of adding "kvm-intel.preemption_timer=0" in another recent > > > thread. This seems to resolve the slowdown issue. > > > > > > However, I have run other guest operating systems on this hardware > > > configuration (CentOS, Ubuntu, FreeBSD) - neither of which required any of > > > these tweaks, or experienced timing issues. This leads me to believe that > > > it > > > could be related to a bug in OpenBSD. > > > > > > I have access to several machines with this hardware configuration and > > > tested on multiple machines, to rule out a possible one-off hardware > > > issue. > > > Each host displayed the same behavior. > > > > > > Best regards, > > > Andrew > > > > > What timecounter source did the OpenBSD guests pick? Did you try selecting > > one of the other choices to see if this helps? > > > > sysctl kern.timecounter if you're not sure what I'm talking about. > > > > -ml >
