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: > > > On Tue, 12 Jun 2012, Daniel Baumann wrote: > > > > On 06/12/2012 06:04 PM, Henrique de Moraes Holschuh wrote: > > > > > I don't care as long as nobody is going to get in the way of an > > > > > urgency=high upload of firmware-nonfree to stable-proposed-updates or > > > > > stable-updates. > > > > > > > > there have been updates of firmware-* packages in the past and more > > > > recently for squeeze too, so i don't think that's a problem. > > > > > > > > > Well, the amd64-microcode has not cleared NEW yet. How should we proceed? > > > > > > > > in my personal opinion, i'd prefere having it integrated into > > > > firmware-nonfree. but it's not my call but the kernel team to decide. > > > > > > Ok, I've looked into firmware-nonfree. > > > > > > The intel and amd64 microcode packages are not simple static data-drop > > > packages (next upload of amd64-microcode will add the required postinst > > > bits). > > > > > > 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? > Adding > MODULE_FIRMWARE() to the amd microcode driver is trivial and I think we > should do it anyway. MODULE_FIRMWARE() is currently impossible for Intel > and unless we want to possibly deviate from upstream, there is no way we can > fix that right now. OK. > > > 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. > > > 2. Ensure that the microcode module and processor microcode will be added > > > to the initramfs. > > > > Can be done by initramfs-tools. > > Yes, it can. But initramfs-tools has no specific code other than some NFS > stuff, so we would probably benefit from a firmware-cpu-tools or whatever, > which could drop the initramfs helper, dpkg triggers and helper scripts to > get things done for both amd and intel microcode. > > I'd rather not duplicate this code for Intel and AMD, so it would need to > end up in a -common/-util package of some sort (or in intramfs-tools > directly, but I don't think that's a good idea): soon we will also need a > new type of hook to piggyback the microcode using a initramfs-like > container, either to the initramfs itself, or to the kernel image (I am not > clear on that detail yet), and the microcode will be loaded on the BSP very > very early, and on other cores BEFORE they're activated. Why is this 'needed'; are future processors expected to be particularly buggy? Named firmware files can generally be included in the kernel image, but of course we won't do that in official Debian packages. > This functionality has not landed in the kernel yet, but since we do know it > is coming, we better make sure we will be able to take advantage of it > without too much packaging rework. A -common/-util package is probably best > for that, and I intend to upload something to that effort this weekend. > > > > This doesn't integrate automatically with firmware-nonfree right now, and I > > > really don't have the time to add support to figure out everything in > > > firmware-nonfree and add these operations to firmware-nonfree right before > > > the freeze, > > [...] > > > > Why don't you upload your package somewhere I can look at it? So far I > > don't see any reason to add a new source package. > > Here: > http://people.debian.org/~hmh/microcode/ > > as one cannot download from the NEW queue, where it is currently. I know, that's why I asked. Thanks. Ben. > The -1 packages are lacking the postinst snippet to refresh microcode, as > that area was in flux over the last few days and I was actively > participating on the thread in LKML to make sure we got something sane for > userspace as the result. > > I was going to add the code to -2, now that the new sysfs nodes are set. It > is in my laptop at home, and I can send it in later today. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong.
Attachment:
signature.asc
Description: This is a digitally signed message part