On Thu, 13 Sep 2012, Wolodja Wentland wrote: > On Mon, Sep 10, 2012 at 11:44 +0200, Marco d'Itri wrote: > > Also, we should mention somewhere (the install documentation?) that > > non-free should be enabled to install microcode fixes which may be > > critical to maintain the system stability. > > Could you elaborate on this please? I have been running systems just fine > even though microcode.ctl (and corresponding microcode) was not installed and > a look at microcode.ctl's popcon [0] confirms that a majority of users do the > same.
Either your system doesn't happen to have a processor with any of the worst bugs, possibly because your BIOS/EFI has up-to-date microcode, or you're just lucky. The kernel could be working with reduced functionality to avoid triggering the bug (it usually logs something when it notices it has to do that), and it is also possible that you just didn't notice any issues because they can be hard to detect. It is a fact that most users consider application or system crashes, lock-ups, and slight malfunctions caused by data corruption to be facts of life, and will blame software bugs first and foremost. As long as they are not too frequent, they will rarely even consider the possibility of hardware problems. > If system stability does, in fact, depend *critically* on the presence of > microcode does this also mean that everybody should install it? What are the > implications of not installing it? The BIOS/EFI will almost always already have a microcode patch level to apply to your processor. You know something had to update the processor microcode if the "microcode" line in /proc/cpuinfo is anything different from zero (requires a recent kernel. 3.2 shows it). So yes, it is very often quite critical. The question then becomes: does your EFI/BIOS have the latest microcode updates? Have you updated your BIOS/EFI recently? Most users _never_ update the system firmware. And some vendors just plain don't release BIOS/EFI updates. System stability depends critically on the presence of microcode that is as up-to-date as required to cover all serious bugs on all features of the processor that your workload uses. So, chances are you don't need it. Or that you need it, but you won't know because it will cause data corruption or some sort of malfunction only once a blue moon and you'd never notice the problem, or you end up blaming it on something else. Maybe you'd benefit from a microcode update, but since it fixes errata that just causes, e.g. slight incorrect performance monitoring, or some waste of power, or some slowdown because the kernel can't do all it should be able to on your processor, you just didn't notice. If you need to know for sure, you have to get the processor errata documentation from Intel or AMD, check the errata list and the list of errata fixed by microcode. Also, these documents are not static, they do get updated when new errata are disclosed. AMD is much better at telling you what they're fixing with a microcode update, the list of errata fixed is already in the README's of the amd64-microcode package so you only need the processor documentation to know what the errata numbers mean. With Intel, you might or might not get a list of errata fixed by a microcode version in the "processor specification update" documents (and usually you don't get anything). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
