Changeset 0576c595


Ignore:
Timestamp:
03/15/2017 03:07:05 AM (7 years ago)
Author:
Ken Moffat <ken@…>
Branches:
10.0, 10.1, 11.0, 11.1, 11.2, 11.3, 12.0, 12.1, 8.1, 8.2, 8.3, 8.4, 9.0, 9.1, basic, bdubbs/svn, elogind, kea, ken/TL2024, ken/inkscape-core-mods, ken/tuningfonts, lazarus, lxqt, perl-modules, plabs/newcss, plabs/python-mods, python3.11, qt5new, rahul/power-profiles-daemon, renodr/vulkan-addition, trunk, upgradedb, xry111/intltool, xry111/llvm18, xry111/soup3, xry111/test-20220226, xry111/xf86-video-removal
Children:
ee4bec2d
Parents:
13b9ae57
Message:

Update the details of how to load CPU microcode.

git-svn-id: svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK@18488 af4574ff-66df-0310-9fd7-8a98e5e911e0

Files:
2 edited

Legend:

Unmodified
Added
Removed

  • introduction/welcome/changelog.xml

    r13b9ae57 r0576c595  
    4646      <itemizedlist>
    4747        <listitem>
     48          <para>[ken] - Change the details of updating microcode in 'About
     49          Firmware' to match what happens in 4.9 kernels. Fixes
     50          <ulink url="&blfs-ticket-root;8963">#8963</ulink>.</para>
     51        </listitem>
     52        <listitem>
    4853          <para>[renodr] - Update to json-glib-1.2.6. Fixes
    4954          <ulink url="&blfs-ticket-root;8997">#8997</ulink>.</para>

  • postlfs/config/firmware.xml

    r13b9ae57 r0576c595  
    9797    need to be applied on every boot.</para>
    9898
    99     <para>There are two ways of loading the microcode, described as 'early' and
    100     'late'. Early loading happens before userspace has been started, late
    101     loading happens when userspace has started. Not surprisingly, early loading
    102     is preferred, (see e.g. an explanatory comment in a kernel commit noted at
     99    <para>Intel provide frequent updates of their microcode. It is not uncommon
     100    to find a newer version of microcode for an Intel processor even two years
     101    after its release. New versions of AMD firmware are less common.</para>
     102
     103    <para>There used to be two ways of loading the microcode, described as 'early'
     104    and 'late'. Early loading happens before userspace has been started, late
     105    loading happens after userspace has started. Not surprisingly, early loading
     106    was preferred, (see e.g. an explanatory comment in a kernel commit noted at
    103107    <ulink url="https://lwn.net/Articles/530346/">x86/microcode: Early load
    104108    microcode </ulink> on LWN.)  Indeed, it is needed to work around one
    … …  
    108112    Intel Disables TSX Instructions: Erratum Found in Haswell, Haswell-E/EP,
    109113    Broadwell-Y</ulink>.) Without this update glibc can do the wrong thing in
    110     uncommon situations.</para>
    111 
    112     <para>It is much simpler to begin by building a kernel which boots on
    113     your hardware, try late microcode loading to see if there is an update (in
    114     many cases the BIOS or UEFI will have already applied any update), and then
    115     take the extra steps required for early loading.</para>
    116 
    117     <para>This means you will be reconfiguring your kernel if you use early
    118     loading, so keep the built source around to minimise what gets rebuilt, and
    119     if you are at all uncertain, add your own identifier (A,B, etc) to the end
    120     of the EXTRAVERSION in the kernel configuration, e.g. "EXTRAVERSION -A" if
    121     nothing was set.</para>
     114    uncommon situations. </para>
     115
     116    <para>As a result, early loading is now expected, although for the moment
     117    (4.9 kernels) it is still possible to manually force late loading of
     118    microcode for testing. You will need to reconfigure your kernel for either
     119    method. The instructions here will create a kernel
     120    <filename>.config</filename> to suite early loading, before forcing late
     121    loading to see if there is any microcode. If there is, the instructions
     122    then show you how to create an initrd for early loading.</para>
    122123
    123124    <para>To confirm what processor(s) you have (if more than one, they will be
    … …  
    126127    <sect3 id="intel-microcode">
    127128      <title>Intel Microcode for the CPU</title>
    128 <!--
    129       <bridgehead renderas="sect4">Required Package</bridgehead>
    130       <para role='required'>
    131          <ulink url='http://fedorahosted.org/released/microcode_ctl/'/></para>
    132 
    133       <para>For Intel CPUs an extra package, microcode_ctl, is required. The
    134       package chosen is the version hosted at fedora &mdash; there is an
    135       alternative version at github from the same packager, but that still
    136       includes a redundant old version of an AMD microcode container, and also
    137       requires the unzip package.</para>
    138 
    139       <para>Download the latest version from the link above; when last checked
    140       this was 2.1-8 and is updated when Intel releases new microcode.</para>
    141 
    142       <para>This package reformats the microcode supplied by Intel into a
    143       format which the kernel can apply. The program
    144       <userinput>intel-microcode2ucode</userinput> is built and invoked by the
    145       Makefile to create the individual firmware blobs, so there is no reason
    146       to install it.</para>
    147 
    148       <para>Begin by extracting the tarball and changing to the directory it created.
    149       Then change to the source directory and run:</para>
    150 
    151 <screen><userinput>make</userinput></screen>
    152 
    153       <para>This creates various blobs with names in the form XX-YY-ZZ. Now you
    154       need to determine your processor's identity, to see if there is any
    155       microcode for it. Determine the decimal values of the cpu family, model
    156       and stepping by running:</para>
    157 -->
    158129
    159130      <bridgehead renderas="sect4">Required File</bridgehead>
    … …  
    201172
    202173      <para>Convert the cpu family, model and stepping to pairs of hexadecimal
    203       digits. For a SandyBridge i3-2120 (described as Intel(R) Core(TM) i3-2120
    204       CPU) the relevant values are cpu family 6, model 42, stepping 7 so in
    205       this case the required identification is 06-2a-07. A look at the blobs
     174      digits. For a Haswell i7-4790 (described as Intel(R) Core(TM) i7-4790
     175      CPU) the relevant values are cpu family 6, model 60, stepping 3 so in
     176      this case the required identification is 06-3c-03. A look at the blobs
    206177      will show that there is one for this CPU (although it might
    207178      have already been applied by the BIOS). If there is a blob for your
    … …  
    213184
    214185      <para>Now that the Intel microcode has been prepared, use the following
    215       options when you configure the kernel to try late loading of the Intel
     186      options when you configure the kernel to load Intel
    216187      microcode:</para>
    217188
    218 <screen><literal>Processor type and features  ---&gt;
    219   &lt;M&gt; CPU microcode loading support  [CONFIG_MICROCODE]
    220   [*]      Intel microcode loading support [CONFIG_MICROCODE_INTEL]</literal></screen>
    221 
    222       <para>After you have successfully booted the new system, use the command
    223       <userinput>dmesg | grep microcode</userinput> and study the results to
    224       see if the message new patch_level appears.  This example from the
    225       SandyBridge i3:</para>
    226 
    227 <screen><literal>[    0.059906] perf_event_intel: PEBS disabled due to CPU errata, please upgrade microcode
    228 [    2.603083] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x23
    229 [    2.669378] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x23
    230 [    2.669994] microcode: CPU0 updated to revision 0x29, date = 2013-06-12
    231 [    2.670069] microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x23
    232 [    2.670139] microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x23
    233 [    2.670501] microcode: CPU1 updated to revision 0x29, date = 2013-06-12
    234 [    2.670509] microcode: CPU2 sig=0x206a7, pf=0x2, revision=0x23
    235 [    2.670540] microcode: CPU2 sig=0x206a7, pf=0x2, revision=0x23
    236 [    2.670917] microcode: CPU2 updated to revision 0x29, date = 2013-06-12
    237 [    2.670955] microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x23
    238 [    2.670988] microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x23
    239 [    2.671348] microcode: CPU3 updated to revision 0x29, date = 2013-06-12
    240 [    2.671356] perf_event_intel: PEBS enabled due to microcode update
    241 [    2.671412] microcode: Microcode Update Driver: v2.00 &lt;tigran@aivazian.fsnet.co.uk&gt;, Peter Oruba</literal></screen>
     189<screen><literal>General Setup ---&gt;
     190  [y] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD]
     191Processor type and features  ---&gt;
     192  [y] CPU microcode loading support  [CONFIG_MICROCODE]
     193  [y]      Intel microcode loading support [CONFIG_MICROCODE_INTEL]</literal></screen>
     194
     195      <para>After you have successfully booted the new system, force late loading by
     196      using the command:</para>
     197
     198<screen><userinput>echo 1 > /sys/devices/system/cpu/microcode/reload</userinput></screen>
     199
     200      <para>Then use the following command to see if anything was loaded:</para>
     201
     202<screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
     203
     204      <para>This example from the Haswell i7 which was released in Q2 2014 and is
     205      not affected by the TSX errate shows it has been updated from revision 0x19
     206      in the BIOS/UEFI to revision 0x20. Unlike in older kernels, the individual
     207      CPUs are not separately reported:</para>
     208
     209<screen><literal>[    0.000000] Linux version 4.9.12 (ken@plexi) (gcc version 6.3.0 (GCC) )
     210               #3 SMP PREEMPT Mon Mar 6 03:29:27 GMT 2017
     211[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.9.12-sda8 root=/dev/sda8 ro
     212[    0.913685] microcode: sig=0x306c3, pf=0x2, revision=0x19
     213[    0.913905] microcode: Microcode Update Driver: v2.01 &lt;tigran@aivazian.fsnet.co.uk&gt;, Peter Oruba
     214[  148.723932] microcode: updated to revision 0x20, date = 2016-03-16</literal></screen>
    242215
    243216    <para>If the microcode was not updated, there is no new microcode for
    … …  
    261234cp -v microcode_amd* /lib/firmware/amd-ucode</userinput></screen>
    262235
    263       <para>When you configure the kernel, use the following options to try
    264       late loading of AMD microcode:</para>
    265 
    266 <screen><literal>Processor type and features  ---&gt;
    267   &lt;M&gt; CPU microcode loading support   [CONFIG_MICROCODE]
    268   [*]   AMD microcode loading support [CONFIG_MICROCODE_AMD]</literal></screen>
    269 
    270       <para>After you have successfully booted the new system, use the command
    271       <userinput>dmesg | grep microcode</userinput> and study the results to see
    272       if the message new patch_level appears, as in this example from an old
    273       Athlon(tm) II X2:</para>
    274 
    275 <screen><literal>[    4.183907] microcode: CPU0: patch_level=0x010000b6
    276 [    4.184271] microcode: CPU0: new patch_level=0x010000c8
    277 [    4.184278] microcode: CPU1: patch_level=0x010000b6
    278 [    4.184283] microcode: CPU1: new patch_level=0x010000c8
    279 [    4.184359] microcode: Microcode Update Driver: v2.00 &lt;tigran@aivazian.fsnet.co.uk&gt;, Peter Oruba</literal></screen>
     236      <para>When you configure the kernel, use the following options when you
     237      configure the kernel to load AMD microcode:</para>
     238
     239<screen><literal>General Setup ---&gt;
     240  [y] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD]
     241Processor type and features  ---&gt;
     242  [y] CPU microcode loading support  [CONFIG_MICROCODE]
     243  [y]      AMD microcode loading support [CONFIG_MICROCODE_AMD]</literal></screen>
     244
     245      <para>After you have successfully booted the new system, force late loading by
     246      using the command:</para>
     247
     248<screen><userinput>echo 1 > /sys/devices/system/cpu/microcode/reload</userinput></screen>
     249
     250      <para>Then use the following command to see if anything was loaded:</para>
     251
     252<screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
     253      <para>This example from an old Athlon(tm) II X2 shows it has been updated.
     254      For the moment, all CPUs are still reported in the microcode details on AMD
     255      machines:</para>
     256
     257<screen><literal>[    0.000000] Linux version 4.9.8 (ken@testserver) (gcc version 6.3.0 (GCC) )
     258               #1 SMP Mon Mar 6 22:27:18 GMT 2017
     259[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.9.8-sdc6 root=/dev/sdc6 ro
     260[    0.907752] microcode: CPU0: patch_level=0x010000b6
     261[    0.907788] microcode: CPU1: patch_level=0x010000b6
     262[    0.907844] microcode: Microcode Update Driver: v2.01 &lt;tigran@aivazian.fsnet.co.uk&gt;, Peter Oruba
     263[  121.952667] microcode: CPU0: new patch_level=0x010000c8
     264[  121.952687] microcode: CPU1: new patch_level=0x010000c8</literal></screen>
    280265
    281266    <para>If the microcode was not updated, there is no new microcode for
    … …  
    290275      <para>If you have established that updated microcode is available for
    291276      your system, it is time to prepare it for early loading. This requires
    292       an additional package, <xref linkend='cpio'/>, as well as changes to
    293       the kernel config and the creation of an initrd which will need to be
    294       added to grub.cfg.</para>
     277      an additional package, <xref linkend='cpio'/> and the creation of an
     278      initrd which will need to be added to grub.cfg.</para>
    295279
    296280      <para>It does not matter where you prepare the initrd, and once it is
    … …  
    316300<screen><userinput>find . | cpio -o -H newc &gt; /boot/microcode.img</userinput></screen>
    317301
    318       <para>You will now need to reconfigure and rebuild your kernel. It is
    319       safer to either add/change the EXTRAVERSION in the kernel's configuration
    320       and install the newer kernel with a new name, or else (unless you have a
    321       machine which requires an early firmware update) wait for the next
    322       SUBLEVEL kernel release so that you can fall back to the existing kernel
    323       in the event that something goes wrong.</para>
    324 
    325       <para>You will also need to add a new entry to /boot/grub/grub.cfg and
     302      <para>You now need to add a new entry to /boot/grub/grub.cfg and
    326303      here you should add a new line after the linux line within the stanza.
    327304      If /boot is a separate mountpoint: </para>
    … …  
    333310<screen><userinput>initrd /boot/microcode.img</userinput></screen>
    334311
    335       <para>You must also change the kernel config:</para>
    336 
    337 <screen><literal>General Setup ---&gt;
    338   [y] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD]
    339   [y] CPU microcode loading support                                  [CONFIG_MICROCODE]</literal></screen>
    340 
    341       <para>Retain the setting for INTEL or AMD microcode. When you have saved
    342       the .config file, either CONFIG_MICROCODE_INTEL_EARLY=y or
    343       CONFIG_MICROCODE_AMD_EARLY=y should be set, together with
    344       CONFIG_MICROCODE_EARLY=y.</para>
    345 
    346       <para>When you have installed and booted this kernel, you should check
    347       the output of dmesg to confirm that the early load worked. The places and
    348       times where this happens are very different in AMD and Intel machines.
    349       First, an Intel example where a development kernel is being tested,
    350       showing that the first notification comes before the kernel version is
    351       mentioned:</para>
    352 
    353 <screen><literal>[    0.000000] CPU0 microcode updated early to revision 0x29, date = 2013-06-12
    354 [    0.000000] Linux version 4.0.0-rc6 (ken@jtm1) (gcc version 4.9.2 (GCC) )
    355                #3 SMP PREEMPT Mon Mar 30 21:26:02 BST 2015
    356 [    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.0.0-rc6-sda13 root=/dev/sda13 ro
    357 ...
    358 [    0.103091] CPU1 microcode updated early to revision 0x29, date = 2013-06-12
    359 [    0.113241]  #2
    360 [    0.134631]  #3
    361 [    0.147821] x86: Booted up 1 node, 4 CPUs
    362 [    0.147936] smpboot: Total of 4 processors activated (26338.66 BogoMIPS)
    363 ...
    364 [    0.272643] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x29
    365 [    0.272709] microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x29
    366 [    0.272775] microcode: CPU2 sig=0x206a7, pf=0x2, revision=0x29
    367 [    0.272842] microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x29
    368 [    0.272941] microcode: Microcode Update Driver: v2.00 &lt;tigran@aivazian.fsnet.co.uk&gt;, Peter Oruba</literal></screen>
    369 
    370       <para>A second AMD example is where the machine was running a stable
    371       kernel on an older version of LFS. Note that here there is no mention of
    372       the previous microcode version &mdash; compare this output to the AMD
    373       late loading messages (above) from the same machine:</para>
    374 
    375 <screen><literal>[    0.000000] Linux version 3.18.11 (ken@milliways) (gcc version 4.9.1 (GCC) )
    376                #4 SMP Thu Apr 9 21:51:05 BST 2015
    377 [    0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.18.11-sda5 root=/dev/sda5 video=800x600 ro
    378 ...
    379 [    0.584009] Trying to unpack rootfs image as initramfs...
    380 [    0.584092] microcode: updated early to new patch_level=0x010000c8
    381 ...
    382 [    0.586733] microcode: CPU0: patch_level=0x010000c8
    383 [    0.586778] microcode: CPU1: patch_level=0x010000c8
    384 [    0.586866] microcode: Microcode Update Driver: v2.00 &lt;tigran@aivazian.fsnet.co.uk&gt;, Peter Oruba</literal></screen>
     312      <para>You can now reboot with the added initrd, and then use the same
     313      command to check that the early load worked.</para>
     314
     315<screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
     316
     317      <para>The places and times where early loading happens are very different
     318      in AMD and Intel machines. First, an Intel example from an updated stable
     319      kernel, showing that the first notification comes before the kernel version
     320      is mentioned:</para>
     321
     322<screen><literal>[    0.000000] microcode: microcode updated early to revision 0x20, date = 2016-03-16
     323[    0.000000] Linux version 4.9.14 (ken@plexi) (gcc version 6.3.0 (GCC) )
     324               #6 SMP PREEMPT Mon Mar 13 16:19:11 GMT 2017
     325[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.9.14-sda8 root=/dev/sda8 ro
     326[    0.920217] microcode: sig=0x306c3, pf=0x2, revision=0x20
     327[    0.920514] microcode: Microcode Update Driver: v2.01 &lt;tigran@aivazian.fsnet.co.uk&gt;, Peter Oruba</literal></screen>
     328
     329      <para>An AMD example for the same kernel version:</para>
     330
     331<screen><literal>[    0.000000] Linux version 4.9.14 (ken@testserver) (gcc version 6.3.0 (GCC) )
     332               #2 SMP Mon Mar 13 22:23:44 GMT 2017
     333[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.9.14-sdc6 root=/dev/sdc6 ro
     334[    0.907648] microcode: microcode updated early to new patch_level=0x010000c8
     335[    0.907690] microcode: CPU0: patch_level=0x010000c8
     336[    0.907733] microcode: CPU1: patch_level=0x010000c8
     337[    0.907808] microcode: Microcode Update Driver: v2.01 &lt;tigran@aivazian.fsnet.co.uk&gt;, Peter Oruba</literal></screen>
    385338
    386339    </sect3>
Note: See TracChangeset for help on using the changeset viewer.