- User Since
- May 26 2014, 3:41 PM (195 w, 6 d)
Thu, Feb 15
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.
Wed, Feb 14
Quick and dirty assessment: BTX panics. :-( More review to come.
Tue, Feb 13
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?
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
Mon, Feb 12
Thu, Feb 1
Wed, Jan 31
Tue, Jan 30
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
Jan 11 2018
This works for my FX-8150:
Update after Intel microcode revert
Blocking pending update for Intel microcode revert.
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
Jan 7 2018
review from mat@
- Drop PORTREVISION (this fixes the build, not needed)
- Use recommended LOCAL/sbruno to indicate where to fetch the AMD microcode tar.
Jan 5 2018
Updated for comments and tested to validate functional AMT console and functional serial console. All looks good from here.
Check against 0xffffffff instead of -1.
Jan 4 2018
Sort new entries to pkg-plist
Clean up tab vs space PORTLINT warning.
Jan 3 2018
@emaste Is this "ok" to commit or is this masking something else going on?