-- updated to Intel Microcode release 0425
-- removed the BDX microcode
-- updated the GLK microcode
-- Modded files/Makefile to be more explicit on which files to process
now that non-microcode files have appeared in the Intel microcode directory
-- intel-ucode-with-caveats/ --
This directory holds microcode that might need special handling.
BDX-ML microcode is provided in directory, because it need special commits in
the Linux kernel, otherwise, updating it might result in unexpected system
behavior.
OS vendors must ensure that the late loader patches (provided in
linux-kernel-patches\) are included in the distribution before packaging the
BDX-ML microcode for late-loading.
== 20180425 Release ==
-- Updates upon 20180312 release --
Processor Identifier Version Products
Model Stepping F-MO-S/PI Old->New
---- updated platforms ------------------------------------
GLK B0 6-7a-1/01 0000001e->00000022 Pentium Silver N/J5xxx, Celeron N/J4xxx
---- removed platforms ------------------------------------
BDX-ML B/M/R0 6-4f-1/ef 0b000021 Xeon E5/E7 v4; Core i7-69xx/68xx
-- Special release with caveats --
BDX-ML B/M/R0 6-4f-1/ef 0b00002c Xeon E5/E7 v4; Core i7-69xx/68xx
Sponsored by: Limelight Networks
- Use new tool committed by Ed Maste of the FreeBSD Foundation to process
Intel microcode files into a format cpucontrol can process.
- Assume maintainer role for the time being. (approved by portmgr)
Reviewed by: delphij emaste
Approved by: portmgr (rene)
Security: yes
Sponsored by: Limelight Networks and The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D15443
Either there is a problem with the Intel supplied microcode files or
cpucontrol does not yet understand how to process a micrcode update file
with multiple entries. For now, abort.
Reviewed by: swills
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D13987
Intel provides prefabricated per-cpu microcode update files. We no longer need
a tool to extract them from the legacy microcode.dat store. This matches
what upstream linux distributions are doing now. Tested on my Intel machines
here and updates still succeed.
Reviewed by: swills cem
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D13921
drop malfunctioning individual "AMD-XXX" files.
On the few machines that actually have microcode updates, chopping up the
microcode is incorrect and results in a failure to update. Don't do that.
I personally run this on my FX-8150 and this has been tested by a few others.
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D13832
literal name_enable wherever possible, and ${name}_enable
when it's not, to prepare for the demise of set_rcvar().
In cases where I had to hand-edit unusual instances also
modify formatting slightly to be more uniform (and in
some cases, correct). This includes adding some $FreeBSD$
tags, and most importantly moving rcvar= to right after
name= so it's clear that one is derived from the other.
