Disabling early microcode, because kernel does not support it. CONFIG_MICROCODE_[AMD|INTEL]_EARLY!=y
"Disabling early microcode, because kernel does not support it. CONFIG_MICROCODE_[AMD|INTEL]_EARLY!=y" seems to be back with all 4.4 kernels, i remember that message due update was fixed in the past
On Mar 6, 2016 6:28 PM, "Reindl Harald" h.reindl@thelounge.net wrote:
"Disabling early microcode, because kernel does not support it.
CONFIG_MICROCODE_[AMD|INTEL]_EARLY!=y" seems to be back with all 4.4 kernels, i remember that message due update was fixed in the past
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.
josh
On 07.03.2016 04:02, Josh Boyer wrote:
On Mar 6, 2016 6:28 PM, "Reindl Harald" h.reindl@thelounge.net wrote:
"Disabling early microcode, because kernel does not support it.
CONFIG_MICROCODE_[AMD|INTEL]_EARLY!=y" seems to be back with all 4.4 kernels, i remember that message due update was fixed in the past 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.
For F23 the dracut update happened weeks before 4.4 hit stable because Harald was asked quite early for a update here: https://bugzilla.redhat.com/show_bug.cgi?id=1278938
@Reindl: you might want to clone the bug to ask Harald for a update in F22 (at least in case nobody filed a proper dracut bug already).
HTH, CU, knurd
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.
Paul Bolle
On Mon, Mar 7, 2016 at 3:13 AM, Paul Bolle pebolle@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.
josh
On Mon, Mar 7, 2016 at 5:16 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Mon, Mar 7, 2016 at 3:13 AM, Paul Bolle pebolle@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.
[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@aivazian.fsnet.co.uk, Peter Oruba [ 1.603190] [drm] Loading TURKS Microcode [chris@f23m Downloads]$ dmesg | grep -i initramfs [ 0.147888] Unpacking initramfs...
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@aivazian.fsnet.co.uk, Peter Oruba [chris@f23s ~]$ dmesg | grep -i initramfs [ 0.267684] Unpacking initramfs...
On Mon, Mar 7, 2016 at 2:16 PM, Chris Murphy lists@colorremedies.com wrote:
On Mon, Mar 7, 2016 at 5:16 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Mon, Mar 7, 2016 at 3:13 AM, Paul Bolle pebolle@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@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@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
On Mon, Mar 7, 2016 at 12:28 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Mon, Mar 7, 2016 at 2:16 PM, Chris Murphy lists@colorremedies.com wrote:
On Mon, Mar 7, 2016 at 5:16 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Mon, Mar 7, 2016 at 3:13 AM, Paul Bolle pebolle@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@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@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.
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
kernel@lists.fedoraproject.org
-
Chris Murphy -
Josh Boyer -
Paul Bolle -
Reindl Harald -
Thorsten Leemhuis