Tue, Mar 20
Wed, Mar 14
Tue, Mar 13
However, %%DATADIR%%/mef406f1_0b000021.fw is listed there, but I have a 2a version in my tree from Intel. Can you confirm that this is the latest version in what's released? The 2a version may be pre-release still.
Otherwise, all the files I care about for $WORK match the latest that we have.
Fri, Mar 9
Thu, Mar 8
I'll grab this and shovel it in after builds are done.
Feb 15 2018
After *READING* the review, I tested with a MAXWAIT of 20 and this works as advertised.
Hmmm ... I'm up to five minutes waiting for a timeout here and I don't even see the twiddle moving.
Feb 14 2018
Quick and dirty assessment: BTX panics. :-( More review to come.
Feb 13 2018
Ugh, phab seems to have not take the diffs from the root of the src tree. I'll munge a bit, but can you regenerate?
Heh, sorry, I ended up creating another review with a different version of that patch: https://reviews.freebsd.org/D14350 -- it turned out there was also a case over in net.c that needed fixing, and we have some timing weirdness happening in the tftp bits to go with it.
Use @kevans version of the patch from private email. Add a debug statement so
I can detect the ETIMEDOUT condition, which does get hit and resumes TFTP without
Feb 12 2018
Feb 1 2018
Jan 31 2018
Jan 30 2018
I'll run this through my local meat grinder and approve/commit after. THANKS
Jan 26 2018
Unrelated, is there a use case for FreeBSD Bhyve here? If we had PF support on FreeBSD, could we use pass through to use VFs?
Jan 19 2018
I will be reverting back to the ucode-tool in the next revision. There is definitely an issue with cpucontrol iterating though an intel microcode file with multiple updates.
Jan 17 2018
It sure looks like there is a problem here.
Jan 16 2018
Let me know if you need me to commit this.
Jan 15 2018
Surprisingly, this seems to work for us.
Jan 14 2018
Jan 13 2018
Your CPU, "family 0xf model 0xb stepping 0x2 extfamily 0 extmodel 0x6" should be 0x60fb2 -- which, yeah, isn't one of 0x600f20, 0x610f01, or 0x600f12. So this microcode file doesn't have an update for your CPU, as I understand it.
I am not sure whether you are correct in this assumption.
The name mangling that is done by ucode-tool is bad and confusing. Imho ucode-tool should be retired, as it is legacy stuff, and the vendor-supplied binary files be used instead for more consistency.
I have done a write-up about this topic on the FreeBSD forums here, where I analyze why the microcode_update thing seems to be broken due to a fundamentally wrong approach.
Jan 11 2018
This works for my FX-8150:
Update after Intel microcode revert
Blocking pending update for Intel microcode revert.
Should this work for Intel cpu's as well? I have a couple servers that use Intel chips, but I have no idea if the microcode is actually being updated. I suspect it is not, x86info -a doesn't provide any information about the microcode.
I found that "chopping up" the AMD microcode files was incorrect (and probably broken for 3+ years). If you have access to AMD hosts, please try my review on your systems. I now get an update to my FX-8150 with my review.
Examining the amd cpucontrol code has led me to realize that chopping up
the microcode files for AMD cpus is exactly wrong. They are already in
the format that corresponds to our processing via "amd10h" so don't do that
Jan 10 2018
Add Family 17h firmware.
Now that the microcode has already been updated, cleanup the review.
Jan 9 2018
It is more than sufficient to check for a non-zero return code from cpucontrol
Redirect cpucontrol error spew to /dev/null when testing -e
Any further objections? I still need to smoke test this a bit too.
When trying to rescan CPU flags, detect versions that don't support -e and error out
Clarify pkg-message to indicate one does not need to reboot to install the microcode
Make "cpucontrol -e" rescan of CPU flags conditional on updating ALL CPUS in the
host system. (gtetlow)
Add a cpucontrol -e after microcode update is complete to re-evaluate
CPU flags. (suggested by bdrewery and cem)
Add pkg-message file to indicate "how" this should be implemented after installing