Bug#676921: ITP: amd64-microcode -- Processor microcode firmware for AMD CPUs
On Sat, 23 Jun 2012, Ben Hutchings wrote:
> On Fri, 2012-06-22 at 23:49 -0300, Henrique de Moraes Holschuh wrote:
> > On Sat, 23 Jun 2012, Ben Hutchings wrote:
> > > On Fri, 2012-06-22 at 16:03 -0300, Henrique de Moraes Holschuh wrote:
> > > > On Fri, 22 Jun 2012, Ben Hutchings wrote:
> > > > > On Sat, 2012-06-16 at 15:08 -0300, Henrique de Moraes Holschuh wrote:
> > > > > > They have to:
> > > > > >
> > > > > > 1. Issue sysfs commands to refresh running microcode
> > > > >
> > > > > With a current kernel, udev will load the firmware just as for any other
> > > > > device.
> > > >
> > > > Yes, it will. At boot. And only if the driver is modular. And only if
> > > > something specifically modprobes microcode, because it has no autoloading
> > > > support in kernel 3.2 and earlier (I think that support was to land in 3.5,
> > > > but it might already have landed in 3.4).
> > > >
> > > > So, Microcode needs to be refreshed when you upgrade the data files, and
> > > > also when the driver is not modular (at least last time I tested it in a 3.0
> > > > kernel for Intel), and that requires postinst and initramfs specific magic
> > > > (quite a lot for Intel, nearly none for AMD).
> > >
> > > > Backporting the autoload code is not straigthforward.
> > >
> > > I backported the general support for x86 CPU module autoloading in
> > > 3.2.21-1. The rest should be easy, shouldn't it?
> >
> > Probably yes.
> >
> > However, the microcode core also went through a large code change
> > because it was ported from half-braindead sysdev to a full blown device.
> > I am not sure if you can do the autoloading properly without that
> > conversion, it depends on whether the code in 3.2 generates the required
> > uevents and sysfs attributes, or not.
> >
> > Do we have a git tree with the Debian kernel somewhere?
>
> The source package is currently still in svn, but there is a git mirror
> of the patched source at
> <http://anonscm.debian.org/gitweb/?p=kernel/linux.git>.
>
> > > > > > and update the initramfs when updated/installed.
> > > > >
> > > > > firmware-nonfree can do that (some network drivers need firmware).
> > > >
> > > > Is it amicable to special postinst code? If it is, it can take care of
> > > > amd64-microcode.
> > >
> > > The package template system currently only supports one optional
> > > postinst action, but it wouldn't be hard to extend to add others.
> >
> > Let's see if I can get that to work over the weekend. I will be unable to
> > do any Debian work next week, which is rather unfortunate given the freeze
> > deadline.
>
> It's not a hard deadline for package updates.
>
> [...]
> > > Why is this 'needed'; are future processors expected to be particularly
> > > buggy?
> >
> > A few current ones already are, and there is no reason to believe it
> > won't happen again in the future. "buggy" here means something the
> > kernel wants (or cannot afford not to) to test for only once, and
> > disable functionality if the relevant microcode update is not already
> > installed in the processor.
>
> Right, good point.
>
> > Anyway, we will need to update the userspace microcode facilities for
> > new kernels, as early-init microcode update support should land in 3.6
> > or 3.7 and will require changes on how it interacts with the initramfs.
> > I'd rather this was something simple to do for wheezy-stable through
> > either a stable update, or a backport or a single simple package.
> [...]
>
> I don't see why that should be included in wheezy.
Maybe as a backport at first. People do like to use more recent kernels
than the stable one with stable userspace... and it would be useful for
wheezy-and-a-half if it comes to happen.
--
"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: