FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 09-13-2012, 09:59 AM
Wolodja Wentland
 
Default Towards d-i wheezy beta 3

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.

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?

[0] http://qa.debian.org/popcon.php?package=microcode.ctl
--
Wolodja <debian@babilen5.org>

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC
 
Old 09-13-2012, 12:17 PM
Henrique de Moraes Holschuh
 
Default 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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120913121749.GA29340@khazad-dum.debian.net">http://lists.debian.org/20120913121749.GA29340@khazad-dum.debian.net
 
Old 09-17-2012, 01:59 PM
Steve McIntyre
 
Default Towards d-i wheezy beta 3

On Mon, Sep 10, 2012 at 12:07:46AM +0200, Cyril Brulebois wrote:
>Hello,
>
>tiny wrap-up for beta 2: the release happened one week after the
>prospective date. Some tiny delays on various fronts added up and
>explain that, but the overall results don't seem too bad to me.
>
>That's why I'm going to propose the same timing for beta 3: 3 weeks for
>development and bug fixes (let's call it a “merge window”), 1 week for
>dealing with udeb-related unblock requests, building/testing images and
>preparing release announcement.
>
>The FTP Team Sprint is scheduled 2012-09-14 → 2012-09-21, but that
>should still leave enough time for development.
>
>Dates would be:
> 2012/09/29-30: d-i wheezy beta 3 merge window closes.
> 2012/10/06-07: d-i wheezy beta 3 is released.
>
>Features expected to be merged:
> - UEFI support (Steve). Before anyone asks, and as far as I can tell:
> it's not about supporting secure boot.
> - IPv6 support in d-i (Philipp).
> - Possibly more xz-related unblocks (Ansgar).
>
>If anybody wants to see something land into this release, it would be
>nice to mention it now instead of after the end of the merge window.

I'd like to get my EFI changes merged, please. A small set of
changes in d-i packages, plus minor bootloader updates. The biggest
change is a tweak to the d-i build process for debian-cd_info.tar.gz
(to add EFI images).

--
Steve McIntyre, Cambridge, UK. steve@einval.com
"You can't barbecue lettuce!" -- Ellie Crane


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120917135918.GD4205@einval.com">http://lists.debian.org/20120917135918.GD4205@einval.com
 

Thread Tools




All times are GMT. The time now is 05:20 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org