On Wed, Oct 26, 2022 at 07:36:28AM -0700, James J. Lippard wrote: > On Wed, Oct 26, 2022 at 04:33:23AM -0500, Scott Cheloha wrote: > > Thank you for testing, let's take a look. > > [...] > > I don't know how to explain this. Maybe another developer will read > > this and spot something I'm missing. Or maybe this is a known issue > > and I'm just not finding a reference to it online. > > > > The simplest workaround is to skip installing acpitimer_delay() with > > delay_init() during acpitimerattach(). The attached patch does this. > > Can confirm that this works.
Good. > > I don't know if this problem persists after boot. If it does, using > > the acpitimer0 timecounter may yield strange results in the VM. I > > recommend not using the acpitimer0 timecounter until the problem is > > better understood. A calibrated TSC is going to be a better > > timecounter anyway. > > > > There might be a second workaround. Kalabic mentions here in the > > other thread about this problem: > > > > https://marc.info/?l=openbsd-bugs&m=166664949825616&w=2 > > > > ... that changing the ESXi option "Guest OS Version" from "FreeBSD > > (32-bit)" to "FreeBSD (64-bit)" seemed to fix the problem on his > > version of ESXi. Does that work for you? I don't know what the other > > consequences of that configuration change are, but it might be worth a > > try if you prefer to run 7.2-RELEASE or 7.2-STABLE instead of patching > > -current. > > I can also confirm that this works as a workaround on the stock 7.2 kernel. > I also booted with the last kernel with debugging info with this workaround; > dmesg for that is below. Even better, and thank you for double-checking with the patched kernel. > > Do you have VMware support? Is there any way for you to report this > > problem to them? It's unlikely they explicitly support running an > > OpenBSD guest, but it's plausible this issue could affect other > > operating systems. I can't imagine OpenBSD is reading the ACPI PM > > timer differently than Linux or FreeBSD. > > Unfortunately not, I only use the free vSphere ESXi. Drat. > OpenBSD 7.2-current (GENERIC.MP) #1: Tue Oct 25 20:09:51 MST 2022 > lipp...@chaos.int.discord.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > [snip] > measure_tsc_freq: indirect calibration with acpitimer0(1000), 3579545 Hz: > count 14211444 14569397 tsc 38873326169 39063325035 usecs 99999: 1900007660 Hz > measure_tsc_freq: direct calibration with acpitimer0(1000), 3579545 Hz: > cycles 357958 tsc 190001742: 1899998842 Hz > measure_tsc_freq: indirect calibration with acpitimer0(1000), 3579545 Hz: > count 14939119 15297049 tsc 39259571275 39449557759 usecs 99993: 1899997839 Hz > measure_tsc_freq: direct calibration with acpitimer0(1000), 3579545 Hz: > cycles 357955 tsc 189999897: 1899996316 Hz > measure_tsc_freq: indirect calibration with acpitimer0(1000), 3579545 Hz: > count 15666102 16024022 tsc 39645448713 39835430133 usecs 99990: 1900004200 Hz > measure_tsc_freq: direct calibration with acpitimer0(1000), 3579545 Hz: > cycles 357954 tsc 189999157: 1899994223 Hz > [snip] > acpihpet0 at acpi0: 14318179 Hz > measure_tsc_freq: indirect calibration with acpihpet0(1000), 14318179 Hz: > count 8315 1439858 tsc 42184173245 42374137028 usecs 99980: 1900017833 Hz > measure_tsc_freq: direct calibration with acpihpet0(1000), 14318179 Hz: > cycles 1431819 tsc 189999907: 1899997610 Hz > measure_tsc_freq: indirect calibration with acpihpet0(1000), 14318179 Hz: > count 2894563 4326110 tsc 42567173659 42757137699 usecs 99981: 1900001400 Hz > measure_tsc_freq: direct calibration with acpihpet0(1000), 14318179 Hz: > cycles 1431826 tsc 190000836: 1899997611 Hz > measure_tsc_freq: indirect calibration with acpihpet0(1000), 14318179 Hz: > count 5781139 7212684 tsc 42950217351 43140181114 usecs 99980: 1900017633 Hz > measure_tsc_freq: direct calibration with acpihpet0(1000), 14318179 Hz: > cycles 1431826 tsc 190000909: 1899998341 Hz This looks right. In summary: - OpenBSD 7.2 amd64 kernel TSC and lapic calibration is broken on (at least) some ESXi 6.0 and ESXi 7.5 hosts under the VM configuration "FreeBSD (32-bit)". The ACPI PM timer seemingly accelerates when we read it repeatedly during boot. - Workaround 1 is to change the configuration to "FreeBSD (64-bit)". - Workaround 2 is to not install acpitimer_delay() with delay_init() during acpitimerattach().
