Updating processor microcode in stable (squeeze)
Please refer to the relevant history at the bottom of this email.
Summary for debian-release:
1. We have AMD and Intel microcode update packages in Wheezy and also in
stable-backports. These packages have been available for a reasonable
amount of time (~two months for AMD, ~three months for Intel), without any
relevant issues (i.e. they're field-tested).
2. Uptake of these packages was low, and only picked up a bit after an
announcement to some Debian MLs. However, once they started being
recommended by the linux-firmware-nonfree packages in Wheeze, there was
an extreme increase of uptake, as far as popcon data can tell
us[1][2][3].
3. These packages fix very relevant, system-crash-class issues as well as
feature issues (such as perf support, power management) for both Intel
and AMD processors. The less tech-savy the user is, the higher the
probability of these packages being useful to the user (due to lack of
BIOS/EFI updates being applied).
4. The microcode packages in stable (squeeze) only cover Intel processors,
and it is also very outdated. Just updating the intel-microcode package
in squeeze would not address the issues of AMD users at all.
5. AMD microcode updates are not easily available in any other way than
distro packages right now. AMD upstream said in LKML that they will sort
it out by the time the next update needs to be published, and likely do
it through the linux-firware.git tree now that amd64.org is no more.
Therefore, I'd like to propose that the packages in debian-backports
(iucode-tool, amd64-microcode, intel-microcode) be uploaded to
stable-proposed-updates. This would add one package to contrib stable
(iucode-tool), add one package to non-free stable (amd64-microcode), and
update one package in non-free stable (intel-microcode).
I'd also propose that the firmware-linux-nonfree package in stable be
updated to "recommends: intel-microcode | amd64-microcode".
If this request is approved by the stable release manager, I'll rebuild the
backport packages with a stable-compatible version before the upload. They
will superseed the backported packages, but still sort before the wheezy
packages to not cause issues with the upgrade path.
Thank you!
[1] http://packages.qa.debian.org/i/intel-microcode.html,
http://qa.debian.org/popcon.php?package=intel-microcode
[2] http://packages.qa.debian.org/a/amd64-microcode.html,
http://qa.debian.org/popcon.php?package=amd64-microcode
[3] http://packages.qa.debian.org/i/iucode-tool.html,
http://qa.debian.org/popcon.php?package=iucode-tool
On Thu, 24 Jan 2013, Ben Hutchings wrote:
> On Thu, 2013-01-24 at 01:00 -0200, Henrique de Moraes Holschuh wrote:
> > On Wed, 23 Jan 2013, Ben Hutchings wrote:
> > > On Wed, Jan 23, 2013 at 11:15:37PM +0200, Touko Korpela wrote:
> > > > When using squeeze system, with wheezy (backports) of kernel and firmware,
> > > > recently firmware-linux started to recommend intel-microcode and
> > > > amd64-microcode packages.
> > > > I think that intel-microcode recommends can be versioned, so that it prefers
> > > > reworked versions (1.20120606.1 or newer) instead of old squeeze version.
> > >
> > > I don't think a versioned Recommends will have the effect you're
> > > hoping for.
> > >
> > > Also if there have been important bug fixes to the microcode then they
> > > should be included in stable-updates, not just squeeze-backports.
> >
> > Ideally, we should get iucode-tool (which would be adding *new* package to
> > stable, something that is extremely rarely done) and the new versions of
> > amd64-microcode (also a new package for stable) and intel-microcode to
> > stable-updates.
> >
> > I can certainly create an old-style intel-microcode package for
> > stable-updates, and that will give non-broken hardware counters for stable
> > Intel users [that run with a custom kernel, stable's doesn't support perf
> > AFAIK]
>
> It does.
>
> > and some nasty bugs removed. But AMD users would still run with
> > microcode that screws up power management, has none/broken hardware counter
> > support, and some nasty bugs that hit rarely.
> >
> > BTW, currently you cannot get AMD microcode updates from anywhere else other
> > than the distros and the internet archive. Makes it somewhat more important
> > to add the package to stable proper, IMHO.
> >
> > Should we take this to the stable release manager?
>
> Please do.
>
> > Good, up-to-date packages *are* available in stable-backports, though.
> > Sending word to the users to install those might make more sense and give
> > better results, as people don't install these microcode packages by
> > themselves. I've seen an absurd increase of popcon results for the two
> > microcode packages since the Recommends was added to firmware-linux.
>
> Well, perhaps that can also be updated.
--
"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: