On Mon, Mar 7, 2016 at 2:16 PM, Chris Murphy <lists(a)colorremedies.com> wrote:
On Mon, Mar 7, 2016 at 5:16 AM, Josh Boyer
<jwboyer(a)fedoraproject.org> wrote:
> On Mon, Mar 7, 2016 at 3:13 AM, Paul Bolle <pebolle(a)tiscali.nl> 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(a)aivazian.fsnet.co.uk>, 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(a)aivazian.fsnet.co.uk>, 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