On 12/13/2013 11:35 PM, Gabe Black wrote:
Defaults should work. Why should I have to know about a magic option that will make my computer not crash at random? If you don't want your computer to work that badly, you should also be motivated enough to find the magic switch that will break it. Breaking people by default in mysterious and unpredictable ways is a terrible idea.
And defaults work. They will continue to work.
On Fri, Dec 13, 2013 at 9:33 PM, mrnuke <mr.nuke.me@gmail.com mailto:mr.nuke.me@gmail.com> wrote:
On 12/13/2013 11:30 PM, Gabe Black wrote: > Processors which need microcode updates? > And how are we breaking them when the defaults don't change? You already have the option, today, to not include microcode updates. It's just not on by default. > On Fri, Dec 13, 2013 at 9:28 PM, mrnuke <mr.nuke.me@gmail.com <mailto:mr.nuke.me@gmail.com> > <mailto:mr.nuke.me@gmail.com <mailto:mr.nuke.me@gmail.com>>> wrote: > > On 12/13/2013 11:24 PM, Gabe Black wrote: > > If you don't want to hear it, ignore it. We shouldn't break things > just > > so people with mistaken opinions are happy, nor how long it took to > > rearrange things into a broken state. > > > What exactly are we breaking? > >
There's a knob. It's called 'microcode updates'. If you set the knob to 'offf' the firmware image you build, and boot, may let the CPU do very bad things to you, in unpredictable ways, at unpredictable times, including (on some CPUs) cause very difficult to detect data corruption because (on some CPUs) there are issues with behavior of shared cache lines or the data path to memory.
The best part? The CPU may behave very well, 999,999,999 times out of 1000000000. It's that last misbehaving time that's going to bite you.
Don't believe me? How about this. I just typed microcode update xeon errata for the heck of it and: "Intel has discovered an erratum with Dual-Core Intel Xeon 5200-series and Quad-Core Intel Xeon 5400-series processors. The potential for this issue to occur does not apply when using Dual-Core Intel Xeon 5000-series, Dual-Core Intel Xeon 5100-series, or Quad-Core Intel Xeon 5300-series processors.
The issue is documented in an updated version of the Intel Processor Specification Update for all affected processors. For additional details regarding the Intel microcode update, reference Errata AX52 (5400-series processors) or Errata AY52 (5200-series processors) in the appropriate Intel Processor Specification Update on the Intel website at the following URL:http://www.intel.com/products/proces...cation_updates
The issue can lead to server hang/reboot and it has been observed to have this effect in recent AppLogic releases. The fix is to have the BIOS of servers using these processors upgraded to a version that resolves these errata."
See those three litle words: "intel microcode update". Oh, and how about "server hang/reboot". Gee, I can build in a 'more free' way if I'm willing to have the occasional hang or reboot. Terrific.
People have ideas about 'free is good, so turning off microcode updates, since it makes the code more free, must be good too'. And that's just plain wrong.
I can't see any redeeming value to the idea of moving the microcode updates into blobs. The point of blobs, when we created it, was to have a place to put things we can't put directly in the coreboot repo. It was never intended to be a destination for things already in the repo. You're misreading the intent of that directory.
And I think it even worse to put the microcode blobs in a location in the tree that implies, by its existence, that you can build without them and get a more free, working firmware image.
That's why I'm so unhappy with this change. I think it's a mistake.
ron
-
mrnuke -
ron minnich