On Mon, Mar 7, 2016 at 2:16 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > On Mon, Mar 7, 2016 at 5:16 AM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: >> On Mon, Mar 7, 2016 at 3:13 AM, Paul Bolle <pebolle@xxxxxxxxxx> wrote: >>> On zo, 2016-03-06 at 22:02 -0500, Josh Boyer wrote: >>>> The functionality is not disabled in the kernel. It was merged into the >>>> main driver and the config options no longer exist. If you aren't seeing >>>> early ucode updates then dracut needs to be updated to deal with 4.4 and >>>> newer kernels. >>> >>> Dracut needs to stop parsing config files (as it apparently does). >>> Kconfig symbols can (and will) change from release to release. They get >>> dropped, change meaning, change from tristate to bool or vice versa, >>> etc, whenever the kernel developers think that's needed. >>> >>> I do not know what dracut is trying to achieve here, but there has got >>> to be a better way to do it. >> >> There is. Dracut has been fixed for a while. Apparently it just >> wasn't backported to f22. > > I'm confused. I see microcode updates applied before initramfs being > unpacked, so how is dracut doing this? This is on Fedora 23. Dracut isn't applying the early ucode updates. It is only responsible for creating an initramfs that contains the microcode in a special section of the CPIO archive. The kernel, having the early ucode functionality, reads this in and applies it before unpacking the rest of the initramfs. > [chris@f23m Downloads]$ dmesg | grep -i microcode > [chris@f23m Downloads]$ dmesg | grep -i microcode > [ 0.000000] microcode: CPU0 microcode updated early to revision > 0x29, date = 2013-06-12 > [ 0.057384] microcode: CPU1 microcode updated early to revision > 0x29, date = 2013-06-12 > [ 0.060449] microcode: CPU2 microcode updated early to revision > 0x29, date = 2013-06-12 > [ 0.063358] microcode: CPU3 microcode updated early to revision > 0x29, date = 2013-06-12 > [ 0.555373] microcode: CPU0 sig=0x206a7, pf=0x10, revision=0x29 > [ 0.555389] microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x29 > [ 0.555450] microcode: CPU2 sig=0x206a7, pf=0x10, revision=0x29 > [ 0.555515] microcode: CPU3 sig=0x206a7, pf=0x10, revision=0x29 > [ 0.555580] microcode: CPU4 sig=0x206a7, pf=0x10, revision=0x29 > [ 0.555605] microcode: CPU5 sig=0x206a7, pf=0x10, revision=0x29 > [ 0.555680] microcode: CPU6 sig=0x206a7, pf=0x10, revision=0x29 > [ 0.555745] microcode: CPU7 sig=0x206a7, pf=0x10, revision=0x29 > [ 0.555958] microcode: Microcode Update Driver: v2.01 > <tigran@xxxxxxxxxxxxxxxxxxxx>, Peter Oruba > [ 1.603190] [drm] Loading TURKS Microcode > [chris@f23m Downloads]$ dmesg | grep -i initramfs > [ 0.147888] Unpacking initramfs... Yes, this is what I would expect on F23 for a machine that has early ucode updates available. > On a different system the timing is reversed: > > [chris@f23s ~]$ dmesg | grep -i microcode > [ 1.128387] microcode: CPU0 sig=0x406c3, pf=0x1, revision=0x35e > [ 1.138941] microcode: CPU1 sig=0x406c3, pf=0x1, revision=0x35e > [ 1.149739] microcode: CPU2 sig=0x406c3, pf=0x1, revision=0x35e > [ 1.152059] microcode: CPU3 sig=0x406c3, pf=0x1, revision=0x35e > [ 1.154580] microcode: Microcode Update Driver: v2.01 > <tigran@xxxxxxxxxxxxxxxxxxxx>, Peter Oruba > [chris@f23s ~]$ dmesg | grep -i initramfs > [ 0.267684] Unpacking initramfs... One of: * The machine doesn't have a dracut that creates the appropriate CPIO (doubtful if it's a fully updated f23) * The firmware set the ucode to something newer than that which is provided by the initramfs, so there is no updating to do * Bug Out of those choices, I would guess the middle one, but that is only a guess. josh _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/kernel@xxxxxxxxxxxxxxxxxxxxxxx
