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. Ben. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong.
signature.asc
Description: This is a digitally signed message part
