Re: Towards d-i wheezy beta 3
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
Reply to: