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. 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. > > 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. > > 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. 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. 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. -- "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-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120622190334.ga32...@khazad-dum.debian.net
