Re: Had to set 'kern.timecounter.hardware' to 'acpitimer0' to fix system clock going too fast
On 25/10/2022 00:17, Kalabic S. wrote: On 24/10/2022 21:31, Scott Cheloha wrote: On Mon, Oct 24, 2022 at 08:26:30AM -0500, Scott Cheloha wrote: On Sun, Oct 23, 2022 at 02:07:12PM +0200, Kalabic S. wrote: [...] machdep.cpuvendor=GenuineIntel machdep.cpuid=0x306a9 machdep.cpufeature=0x1fbbfbff machdep.tscfreq=745206414 machdep.invarianttsc=1 And yeah, your TSC frequency is astoundingly high. Way higher than anything I have ever seen. Sorry, what I should have said was: that TSC frequency is too *low* for your machine. I miscounted the number of decimal digits. To be clear: the measured TSC frequency of 745 MHz seems too low. There is something probably relevant that I noticed while setting up a new VM guest to try to compile the kernel as advised. So, ISO used was a current snapshot (sha256: 29d320ae1a...), and as always in "VM Options" under "General Options", "Guest OS Version" was set to "FreeBSD (32-bit)". Issue with clock running forward is again reproduced. Being curious what would happen if that same option was set to "FreeBSD (64-bit)" I tried it and the clock issue is gone! (but ESXi now shows a warning in web GUI: 'The configured guest OS (FreeBSD (64-bit)) for this virtual machine does not match the guest that is currently running (FreeBSD (32-bit)). ...') Attached are dmesg, sysctl hw and sysctl machdep outputs from this new VM running with both 32 and 64 bit settings. *Nothing* else was changed, virtual machine was untouched after installation. Notable difference is machdep.tscfreq=3392313140 (64-bit) vs 744231460 for 32-bit setting. Hope this helps for now. Just noticed hw.sensors.vmt0.timedelta0 and hw.cpuspeed are also different depending on Guest OS Version option! For 32-bit option (reproducible clock issue): hw.sensors.vmt0.timedelta0=738.817611 secs hw.cpuspeed=744 For 64-bit option (no clock issue): hw.sensors.vmt0.timedelta0=941.876986 secs hw.cpuspeed=3392
Re: Had to set 'kern.timecounter.hardware' to 'acpitimer0' to fix system clock going too fast
On 24/10/2022 21:31, Scott Cheloha wrote: On Mon, Oct 24, 2022 at 08:26:30AM -0500, Scott Cheloha wrote: On Sun, Oct 23, 2022 at 02:07:12PM +0200, Kalabic S. wrote: [...] machdep.cpuvendor=GenuineIntel machdep.cpuid=0x306a9 machdep.cpufeature=0x1fbbfbff machdep.tscfreq=745206414 machdep.invarianttsc=1 And yeah, your TSC frequency is astoundingly high. Way higher than anything I have ever seen. Sorry, what I should have said was: that TSC frequency is too *low* for your machine. I miscounted the number of decimal digits. To be clear: the measured TSC frequency of 745 MHz seems too low. There is something probably relevant that I noticed while setting up a new VM guest to try to compile the kernel as advised. So, ISO used was a current snapshot (sha256: 29d320ae1a...), and as always in "VM Options" under "General Options", "Guest OS Version" was set to "FreeBSD (32-bit)". Issue with clock running forward is again reproduced. Being curious what would happen if that same option was set to "FreeBSD (64-bit)" I tried it and the clock issue is gone! (but ESXi now shows a warning in web GUI: 'The configured guest OS (FreeBSD (64-bit)) for this virtual machine does not match the guest that is currently running (FreeBSD (32-bit)). ...') Attached are dmesg, sysctl hw and sysctl machdep outputs from this new VM running with both 32 and 64 bit settings. *Nothing* else was changed, virtual machine was untouched after installation. Notable difference is machdep.tscfreq=3392313140 (64-bit) vs 744231460 for 32-bit setting. Hope this helps for now.OpenBSD 7.2-current (GENERIC.MP) #809: Mon Oct 24 10:29:46 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1055850496 (1006MB) avail mem = 1006489600 (959MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (556 entries) bios0: vendor Phoenix Technologies LTD version "6.00" date 09/21/2015 bios0: VMware, Inc. VMware Virtual Platform acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S8F0(S3) S16F(S3) S17F(S3) S18F(S3) S22F(S3) S23F(S3) S24F(S3) S25F(S3) PE40(S3) S1F0(S3) PE50(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz, 744.29 MHz, 06-3a-09 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 6MB 64b/line 12-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 14MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz, 745.91 MHz, 06-3a-09 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,MELTDOWN cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 6MB 64b/line 12-way L3 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf000, bus 0-127 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 "PNP0A05" at acpi0 not configured acpiac0 at acpi0: AC unit online acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) cpu0: using VERW MDS workaround pvbus0 at mainbus0: VMware vmt0 at pvbus0 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01 ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01 pci1 at ppb0 bus 1 pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x08 pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility pciide0: channel 0 disabled (no drives) pciide0: channel 1 disabled (no drives) piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x08: SMBus disabled "VMware VMCI" rev 0x10 at pci0 dev 7 function 7 not configured vga1 at pci0 dev 15 function 0 "VMware SVGA II" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) mpi0 at pci0 dev 16 function 0 "Symbios Logic
Re: Had to set 'kern.timecounter.hardware' to 'acpitimer0' to fix system clock going too fast
On Mon, Oct 24, 2022 at 08:26:30AM -0500, Scott Cheloha wrote: > On Sun, Oct 23, 2022 at 02:07:12PM +0200, Kalabic S. wrote: > > [...] > > > machdep.cpuvendor=GenuineIntel > > machdep.cpuid=0x306a9 > > machdep.cpufeature=0x1fbbfbff > > machdep.tscfreq=745206414 > > machdep.invarianttsc=1 > > And yeah, your TSC frequency is astoundingly high. Way higher than > anything I have ever seen. Sorry, what I should have said was: that TSC frequency is too *low* for your machine. I miscounted the number of decimal digits. To be clear: the measured TSC frequency of 745 MHz seems too low.
Re: Had to set 'kern.timecounter.hardware' to 'acpitimer0' to fix system clock going too fast
On 24/10/2022 15:26, Scott Cheloha wrote: machdep.cpuvendor=GenuineIntel machdep.cpuid=0x306a9 machdep.cpufeature=0x1fbbfbff machdep.tscfreq=745206414 machdep.invarianttsc=1 And yeah, your TSC frequency is astoundingly high. Way higher than anything I have ever seen. My guess is that we are miscalibrating the TSC frequency at least once. The only major thing that changed in the frequency calibration code between 7.1 and 7.2 is the introduction of additional delay(9) implementations. Let's see if removing them from the picture changes the result we get. Can you compile and boot a -current kernel with the attached patch and send the resulting dmesg? Yes I could, but it will take me some time, I never ever compiled a kernel :D
Re: Had to set 'kern.timecounter.hardware' to 'acpitimer0' to fix system clock going too fast
On 24/10/2022 15:26, Scott Cheloha wrote: Please provide a dmesg and the output of $ sysctl hw and $ sysctl machdep A dmesg from the VM before you upgraded will also help. I'm not seeing one here. I guess I'll just do a little guesswork. Well only thing I could do is install a new 7.1 guest on the same ESXi host and I did just that now. Here they are attached to this mail. OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 18:03:57 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1055850496 (1006MB) avail mem = 1006624768 (959MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (556 entries) bios0: vendor Phoenix Technologies LTD version "6.00" date 09/21/2015 bios0: VMware, Inc. VMware Virtual Platform acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S8F0(S3) S16F(S3) S17F(S3) S18F(S3) S22F(S3) S23F(S3) S24F(S3) S25F(S3) PE40(S3) S1F0(S3) PE50(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz, 3392.99 MHz, 06-3a-09 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 65MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz, 3392.41 MHz, 06-3a-09 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: disabling user TSC (skew=-6189) cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf000, bus 0-127 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 "PNP0A05" at acpi0 not configured acpiac0 at acpi0: AC unit online acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) cpu0: using VERW MDS workaround pvbus0 at mainbus0: VMware vmt0 at pvbus0 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01 ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01 pci1 at ppb0 bus 1 pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x08 pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility pciide0: channel 0 disabled (no drives) pciide0: channel 1 disabled (no drives) piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x08: SMBus disabled "VMware VMCI" rev 0x10 at pci0 dev 7 function 7 not configured vga1 at pci0 dev 15 function 0 "VMware SVGA II" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) mpi0 at pci0 dev 16 function 0 "Symbios Logic 53c1030" rev 0x01: apic 2 int 17 mpi0: 0, firmware 1.3.41.32 scsibus1 at mpi0: 16 targets, initiator 7 sd0 at scsibus1 targ 0 lun 0: sd0: 32768MB, 512 bytes/sector, 67108864 sectors mpi0: target 0 Sync at 160MHz width 16bit offset 127 QAS 1 DT 1 IU 1 ppb1 at pci0 dev 17 function 0 "VMware PCI" rev 0x02 pci2 at ppb1 bus 2 uhci0 at pci2 dev 0 function 0 "VMware UHCI" rev 0x00: apic 2 int 18 em0 at pci2 dev 1 function 0 "Intel 82545EM" rev 0x01: apic 2 int 19, address 00:0c:29:ba:42:cd ehci0 at pci2 dev 2 function 0 "VMware EHCI" rev 0x00: apic 2 int 16 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "VMware EHCI root hub" rev 2.00/1.00 addr 1 ahci0 at pci2 dev 4 function 0 "VMware AHCI" rev 0x00: msi, AHCI 1.3 ahci0: port 0: 6.0Gb/s scsibus2 at ahci0: 32 targets cd0 at scsibus2 targ 0 lun 0: removable usb1 at uhci0: USB revision 1.0 uhub1 at usb1 configuration 1 interface 0 "VMware UHCI root hub" rev 1.00/1.00 addr 1 ppb2 at pci0 dev 21 function 0 "VMware PCIE" rev 0x01: msi pci3 at ppb2 bus 3 ppb3 at pci0 dev 21 function 1 "VMware PCIE" rev 0x01: msi pci4 at ppb3 bus 4 ppb4 at pci0 dev 21 function 2 "VMware PCIE" rev 0x01: msi pci5 at ppb4 bus 5 ppb5 at pci0 dev 21 function 3 "VMware PCIE" rev 0x01: msi pci6 at ppb5 bus 6 ppb6 at pci0 dev 21 function 4 "VMware PCIE" rev 0x01: msi pci7 at ppb6 bus 7 ppb7
Re: Had to set 'kern.timecounter.hardware' to 'acpitimer0' to fix system clock going too fast
On 2022/10/24 08:26, Scott Cheloha wrote: > > pppoe0: received unexpected PADO > > [snip] > > pppoe0: received unexpected PADO > > pppoe0: LCP keepalive timeout > > [snip] > > pppoe0: host unique tag found, but it belongs to a connection in state 3 > > pppoe: received PADO but could not find request for it > > pppoe0: LCP keepalive timeout > > pppoe0: received unexpected PADO > > [snip] > > pppoe0: received unexpected PADO > > I assume you didn't see these messages on 7.1? Unlikely to be related to the time issues. These can happen if the machine is restarted without bringing down the connection nicely first and the ISP holds onto the old session for a while. "ifconfig pppoe0 down" in rc.shutdown, possibly followed by a short sleep, might help with those.
Re: Had to set 'kern.timecounter.hardware' to 'acpitimer0' to fix system clock going too fast
On Sun, Oct 23, 2022 at 02:07:12PM +0200, Kalabic S. wrote: > On 23/10/2022 12:28, Scott Cheloha wrote: > > On Fri, Oct 21, 2022 at 12:28:26AM +0200, Kalabic S. wrote: > > > Hello, > > > > > > I noticed a system clock issue after upgrade from 7.1 to 7.2, clock > > > started > > > to run really fast, almost at 10x speed or so. It is a virtual machine > > > guest > > > on ESXi 6.0 host, VM is used as a main Internet router for my home network > > > (PPPoE over fiber). Both host and VM are configured with date/time in UTC > > > timezone. > > > > > > Long story short, setting 'kern.timecounter.hardware' to 'acpitimer0' has > > > fixed it. > > > > > > It did not make any difference if ntpd service was enabled or disabled. > > > > Please provide a dmesg and the output of > > > > $ sysctl hw > > > > and > > > > $ sysctl machdep > > > > A dmesg from the VM before you upgraded will also help. I'm not seeing one here. I guess I'll just do a little guesswork. > > If you have some kind of configuration file for the ESXi host and the > > VM, that will also help. I don't know anything about ESXi, but it > > will help to look at what sort of settings you are using. Also not seeing this here. If you provide one it might save a lot of time chasing non-problems. > Attached output to this mail. Thanks, let's take a peek. > OpenBSD 7.2 (GENERIC.MP) #758: Tue Sep 27 11:57:54 MDT 2022 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 1055850496 (1006MB) > avail mem = 1006510080 (959MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (556 entries) > bios0: vendor Phoenix Technologies LTD version "6.00" date 09/21/2015 > bios0: VMware, Inc. VMware Virtual Platform Okay, we're in a VMware guest, no surprises there. > acpi0 at bios0: ACPI 4.0 > acpi0: sleep states S0 S1 S4 S5 > acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET > acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S8F0(S3) > S16F(S3) S17F(S3) S18F(S3) S22F(S3) S23F(S3) S24F(S3) S25F(S3) PE40(S3) > S1F0(S3) PE50(S3) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits You have a 24-bit virtual ACPI PM timer. At this point in the boot, we will have switched from i8254_delay() to using acpitimer_delay(). We probably also calibrate the TSC with acpitimer(4) here, or near here. > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz, 745.35 MHz, 06-3a-09 The bogomips measurement is very, very low compared to the speed advertised in the CPU string. Not necessarily an error, but odd-looking, even in a VM. > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,MELTDOWN TSC-related feature flags: TSC, DEADLINE, RDTSCP, ITSC, TSC_ADJUST > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 6MB 64b/line 12-way L3 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 15MHz This looks low. I don't know precisely what the hypervisor does to the local apic timer frequency, and I don't have an old dmesg for reference, but my guess is that this value is wrong. At this point in the boot we have switched from acpitimer_delay() to lapic_delay(). > cpu1 at mainbus0: apid 1 (application processor) > cpu1: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz, 813.12 MHz, 06-3a-09 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,MELTDOWN > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 6MB 64b/line 12-way L3 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 2 (application processor) > cpu2: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz, 813.24 MHz, 06-3a-09 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,MELTDOWN > cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 6MB 64b/line 12-way L3 cache > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 3 (application processor) > cpu3: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz,
Re: Apparently 7.2 broke "fn" button on macbook air
> >Synopsis:fn key stopped working after upgrade > >Category:kernel > >Environment: > System : OpenBSD 7.2 > Details : OpenBSD 7.2 (GENERIC.MP) #758: Tue Sep 27 11:57:54 MDT > 2022 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > I've just upgraded my computer from 7.1. Prior to upgrade, I could use > "fn" key with volume control and arrow keys (i.e. fn+F10 would toggle > mute state, fn+F11 would decrease volume, fn+up arrow would generate > page up event. This stopped to work after 7.2 upgrade. Above key > combinations now generate the same events as only the primary key was > pressed. This is indeed a 7.2 regression, and got fixed in sys/dev/usb/ukbd.c r1.88. Miod
