Extend the port so that users may easily apply microcode updates using
the method implemented in src r337715. For now, this just consists of
providing all Intel microcode update files concatenated together as a
single blob in /boot/firmware.
Approved by: sbruno
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D16924
- Update Intel microcode to 0703 release.
-- 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.
== 20180703 Release ==
-- Updates upon 20180425 release --
Processor Identifier Version Products
Model Stepping F-MO-S/PI Old->New
---- updated platforms ------------------------------------
SNB-EP C1 6-2d-6/6d 0000061c->0000061d Xeon E5
SNB-EP C2 6-2d-7/6d 00000713->00000714 Xeon E5
IVT C0 6-3e-4/ed 0000042c->0000042d Xeon E5 v2;
Core i7-4960X/4930K/4820K
IVT D1 6-3e-7/ed 00000713->00000714 Xeon E5 v2
HSX-E/EP/4S C0 6-3f-2/6f 0000003c->0000003d Xeon E5 v3
HSX-EX E0 6-3f-4/80 00000011->00000012 Xeon E7 v3
SKX-SP/D/W/X H0 6-55-4/b7 02000043->0200004d Xeon Bronze 31xx,
Silver 41xx, Gold 51xx/61xx Platinum 81xx, D/W-21xx; Core i9-7xxxX
BDX-DE A1 6-56-5/10 0e000009->0e00000a Xeon D-15x3N
---- intel-ucode-with-caveats/ ----------------------------
BDX-ML B/M/R0 6-4f-1/ef 0b00002c->0b00002e Xeon E5/E7 v4; Core i7-69xx/68xx
Reviewed by: swills
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D16209
-- 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
FreeBSD kernel changes to make use of the capabilities provided by the
new microcode update have not yet been committed. Since we do not yet
require them, allow more time for validation.
Approved by: emaste
Sponsored by: Limelight Networks
Use a freebsd.org hosted version of the amd microcode file fetched
in February of 2015. The amd64.org site has been down for a long time and
probably will never come back.
Reported by: netchild
Reviewed by: mat antoine
Approved by: portmgr (mat@ antoin@)
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D13792
- Update MASTER_SITES: use https:// for Intel
- While I'm here, add NO_ARCH
PR: 219268
Submitted by: grarpamp <grarpamp@gmail.com>
Approved by: John Clark <clarkjc@runbox.com> (maintainer)
- Accept LICENSE since it allows mirroring [1]
PR: 215104
Approved by: John Clark <clarkjc@runbox.com> (maintainer)
Submitted by: John Clark <clarkjc@runbox.com> [1]
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.
my ports in the past 3 weeks while ports were broken on any 10.x
machines, which means I'm unable to maintain them. So let people know
that there's no available support for them until things are back to
normal (which also means that anyone with spare time will be able
to fix them without getting approval).
