Re: git: 64880edb1ae1 - main - sysutils/cpu-microcode-intel: Update to 2026-05-12 release

In reply to: Joseph Mingrone : "Re: git: 64880edb1ae1 - main - sysutils/cpu-microcode-intel: Update to 2026-05-12 release"
Go to: [ bottom of page ] [ top of archives ] [ this month ]

From: Nuno Teixeira <eduardo_at_freebsd.org>
Date: Wed, 13 May 2026 17:04:55 UTC

Hello!

CPU: Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz (2600.00-MHz K8-class CPU)

I've changed to rc script and service onestart did start OK and dmesg shows:

---
CPU: Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz (2592.00-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0xa0652  Family=0x6  Model=0xa5  Stepping=2

Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>

Features2=0x7ffafbbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
  AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
  AMD Features2=0x121<LAHF,ABM,Prefetch>
  Structured Extended
Features=0x29c67af<FSGSBASE,TSCADJ,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,NFPUSG,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PROCTRACE>
  Structured Extended Features2=0x40000018<PKU,OSPKE,SGXLC>
  Structured Extended
Features3=0xbc000600<MCUOPT,MD_CLEAR,IBPB,STIBP,L1DFL,ARCH_CAP,SSBD>
  XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
  IA32_ARCH_CAPS=0xa0a0c2b<RDCL_NO,IBRS_ALL,SKIP_L1DFL_VME,MDS_NO>
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr
  TSC: P-state invariant, performance statistics
---

I will subscribe to PR and do some loader.conf run-tests from time to time.

Thanks,

Joseph Mingrone <jrm@freebsd.org> escreveu (quarta, 13/05/2026 à(s) 17:31):

> On Wed, 2026-05-13 at 16:22, Nuno Teixeira <eduardo@freebsd.org> wrote:
> > .bin is huge around 16M, is that normal?
>
> Yes, because all the microcode under intel-ucode/ is concatenated in the
> post-extract target.  That's microcode covering CPUs from Pentium
> Pro-era chips through to Granite Rapids/Arrow Lake.  It does this
> because the loader accepts a blob and loops over the entries in that
> blob and checks whether the signature and platform flags match the
> current CPU.
>
> Joe
>


-- 
Nuno Teixeira
FreeBSD UNIX:  <eduardo@FreeBSD.org>   Web:  https://FreeBSD.org