On Mon, Mar 7, 2016 at 12:28 PM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > 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. It's also a Fedora 23 system, same kernel, same version of dracut. But it's an Intel NUC with a firmware that's maybe 4 months old. So I think the guess is probably correct. > > josh -- Chris Murphy _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/kernel@xxxxxxxxxxxxxxxxxxxxxxx
