Changeset f2d867ab
- Timestamp:
- 06/06/2022 04:29:45 PM (23 months ago)
- Branches:
- 11.2, 11.3, 12.0, 12.1, kea, ken/TL2024, ken/inkscape-core-mods, ken/tuningfonts, lazarus, lxqt, plabs/newcss, plabs/python-mods, python3.11, qt5new, rahul/power-profiles-daemon, renodr/vulkan-addition, trunk, xry111/llvm18, xry111/soup3, xry111/xf86-video-removal
- Children:
- ea7594d
- Parents:
- 384a4b1 (diff), 3b50f0de (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the(diff)
links above to see all the changes relative to each parent. - File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
postlfs/config/firmware.xml
r384a4b1 rf2d867ab 160 160 161 161 <para> 162 There are two ways of loading the microcode, described as 'early' and162 There were two ways of loading the microcode, described as 'early' and 163 163 'late'. Early loading happens before userspace has been started, late 164 loading happens after userspace has started. Not surprisingly, early165 loading is preferred, (see e.g. an explanatory comment in a kernel166 commit noted at <ulink url="https://lwn.net/Articles/530346/">167 x86/microcode: Early load microcode</ulink> on LWN.) Indeed, it168 is needed to work around one particular erratum in early Intel Haswell169 processors which had TSX enabled. (See <ulink url=164 loading happens after userspace has started. However, late loading is 165 known to be problematic and not supported anymore (see the kernel commit 166 <ulink url="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d23d33e"> 167 x86/microcode: Taint and warn on late loading</ulink>.) Indeed, early 168 loading is needed to work around one particular erratum in early Intel 169 Haswell processors which had TSX enabled. (See <ulink url= 170 170 "http://www.anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-in-haswell-haswelleep-broadwellyi/"> 171 171 Intel Disables TSX Instructions: Erratum Found in Haswell, 172 Haswell-E/EP, Broadwell-Y 173 </ulink>.)Without this update glibc can do the wrong thing in uncommon172 Haswell-E/EP, Broadwell-Y</ulink>.) 173 Without this update glibc can do the wrong thing in uncommon 174 174 situations. 175 175 </para> … … 185 185 186 186 <para> 187 It is still possible to manually force late loading of microcode, either 188 for testing or to prevent having to reboot. You will need to reconfigure 189 your kernel for either method. The instructions here will create a 190 kernel <filename>.config</filename> to suite early loading, before 191 forcing late loading to see if there is any microcode. If there is, 192 the instructions then show you how to create an initrd for early loading. 193 It is also possible to build the same microcode bin file into the kernel, 194 which allows early loading but requires the kernel to be recompiled to 195 update the microcode 187 It might be still possible to manually force late loading of microcode. 188 But it may cause kernel malfunction and you should take the risk yourself. 189 You will need to reconfigure your kernel for either method. The 190 instructions here will show you how to create an initrd for early 191 loading. It is also possible to build the same microcode bin file into 192 the kernel, which allows early loading but requires the kernel to be 193 recompiled to update the microcode. 196 194 </para> 197 195 … … 206 204 207 205 <para> 208 Convert the cpu family, model and stepping to pairs of hexadecimal digits. 206 Convert the cpu family, model and stepping to pairs of hexadecimal 207 digits, and remember the value of the <quote>microcode</quote> field. 209 208 You can now check if there is any microcode available. 210 209 </para> … … 239 238 <para> 240 239 In the past, intel did not provide any details of which blobs had 241 changed versions, but now the releasenote details this. 240 changed versions, but now the releasenote details this. You can 241 compare the microcode version in <filename>/proc/cpuinfo</filename> 242 with the version for your CPU model in the releasenote to know if 243 there is an update. 242 244 </para> 243 245 … … 253 255 254 256 <para> 255 For a Skylake i3 6100 (described as Intel(R) Core(TM) i3-6100 256 CPU) the relevant values are cpu family 6, model 94, stepping 3 so in 257 this case the required identification is 06-5e-03. A look at the blobs 258 will show that there is one for this CPU (although for older issues it 259 might have already been applied by the BIOS). 260 If there is a blob for 261 your system then test if it will be applied by copying it (replace 262 <XX-YY-ZZ> by the identifier for your CPU) to where the 263 kernel can find it: 264 </para> 265 266 <screen><userinput>mkdir -pv /lib/firmware/intel-ucode 267 cp -v intel-ucode/<XX-YY-ZZ> /lib/firmware/intel-ucode</userinput></screen> 268 269 <para> 270 Now that the Intel microcode has been prepared, use the following 271 options when you configure the kernel to load Intel microcode: 257 For an Icelake mobile (described as Intel(R) Core(TM) i7-1065G7 258 CPU) the relevant values are cpu family 6, model 126, stepping 5 so 259 in this case the required identification is 06-7e-05. The 260 releasenote says the latest microcode for it is versioned 0xb0. If 261 the value of the <quote>microcode</quote> field in 262 <filename>/proc/cpuinfo</filename> is 0xb0 or greater, it indicates 263 the microcode update is already applied by the BIOS. Otherwise, 264 configure the kernel to support loading Intel microcode, and then 265 proceed to <xref linkend='early-microcode'/>: 272 266 </para> 273 267 … … 277 271 [*] CPU microcode loading support [CONFIG_MICROCODE] 278 272 [*] Intel microcode loading support [CONFIG_MICROCODE_INTEL]</literal></screen> 279 280 <para>281 After you have successfully booted the new system, force late loading282 by using the command:283 </para>284 285 <screen><userinput>echo 1 > /sys/devices/system/cpu/microcode/reload</userinput></screen>286 287 <para>288 Then use the following command to check if anything was loaded:289 (N.B. the dates when microcode was created may be months ahead of when290 it was released.)291 </para>292 293 <screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>294 295 <para>296 This old example showing the very old BIOS firmware version297 was created by temporarily booting without298 microcode, to show the current Firmware Bug messages, then the late load299 shows it being updated to revision 0xea which was current at that time.300 </para>301 302 <screen><literal>[ 0.000000] Linux version 5.12.8 (lfs@leshp) (gcc (GCC) 11.1.0,303 GNU ld (GNU Binutils) 2.36.1)304 #2 SMP PREEMPT Fri Jun 4 01:25:02 BST 2021305 [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.12.8-sda11 root=/dev/sda11 ro306 resume=/dev/sda10307 [ 0.028741] [Firmware Bug]: TSC_DEADLINE disabled due to Errata;308 please update microcode to version: 0xb2 (or later)309 [ 0.115716] SRBDS: Vulnerable: No microcode310 [ 0.115826] MDS: Vulnerable: Clear CPU buffers attempted, no microcode311 [ 0.389005] microcode: sig=0x506e3, pf=0x2, revision=0x74312 [ 0.389030] microcode: Microcode Update Driver: v2.2.313 [ 70.089502] microcode: updated to revision 0xea, date = 2021-01-25314 [ 70.089528] x86/CPU: CPU features have changed after loading microcode,315 but might not take effect.316 [ 70.089530] microcode: Reload completed, microcode revision: 0xea</literal></screen>317 318 <para>319 If the microcode was not updated, there is no new microcode for this320 system's processor. If it did get updated, you can now proceed to321 <xref linkend='early-microcode'/>.322 </para>323 273 324 274 </sect3> … … 343 293 For the very old Athlon(tm) II X2 in these examples the values were 344 294 cpu family 16, model 5, stepping 3 giving an identification of 345 Family=0x10 Model=0x05 Stepping=0x03 346 </para> 347 348 <para> 349 If you wish to try late loading, 350 create the required directory and put the firmware you 351 downloaded into it as the <systemitem 352 class="username">root</systemitem> user: 353 </para> 354 355 <screen><userinput>mkdir -pv /lib/firmware/amd-ucode 356 cp -v microcode_amd* /lib/firmware/amd-ucode</userinput></screen> 357 358 <para> 359 When you configure the kernel, use the following options 360 to load AMD microcode: 295 Family=0x10 Model=0x05 Stepping=0x03. One line of the 296 <command>amd_ucode_info.py</command> script output describes the 297 microcode version for it: 298 </para> 299 300 <screen><computeroutput>Family=0x10 Model=0x05 Stepping=0x03: Patch=0x010000c8 Length=960 bytes</computeroutput></screen> 301 302 <para> 303 If the value of the <quote>microcode</quote> field in 304 <filename>/proc/cpuinfo</filename> is 0x10000c8 or greater, it 305 indicates the BIOS has already applied the microcode update. 306 Otherise, configure the kernel to support loading AMD microcode, 307 and then proceed to <xref linkend='early-microcode'/>: 361 308 </para> 362 309 … … 366 313 [*] CPU microcode loading support [CONFIG_MICROCODE] 367 314 [*] AMD microcode loading support [CONFIG_MICROCODE_AMD]</literal></screen> 368 369 <para>370 After you have successfully booted the new system, force late loading371 by using the command:372 </para>373 374 <screen><userinput>echo 1 > /sys/devices/system/cpu/microcode/reload</userinput></screen>375 376 <para>377 Then use the following command to check if anything was loaded:378 </para>379 380 <screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>381 <para>382 This historic example from an old Athlon(tm) II X2 shows it has been383 updated. At that time, all CPUs were still reported in the microcode384 details on AMD machines (the current position for AMD machines where385 newer microcode is available is unknown) :386 </para>387 388 <screen><literal>[ 0.000000] Linux version 4.15.3 (ken@testserver) (gcc version 7.3.0 (GCC))389 #1 SMP Sun Feb 18 02:08:12 GMT 2018390 [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.15.3-sda5 root=/dev/sda5 ro391 [ 0.307619] microcode: CPU0: patch_level=0x010000b6392 [ 0.307671] microcode: CPU1: patch_level=0x010000b6393 [ 0.307743] microcode: Microcode Update Driver: v2.2.394 [ 187.928891] microcode: CPU0: new patch_level=0x010000c8395 [ 187.928899] microcode: CPU1: new patch_level=0x010000c8</literal></screen>396 397 <para>398 If the microcode was not updated, there is no new microcode for399 this system's processor. If it did get updated, you can now proceed to400 <xref linkend='early-microcode'/>.401 </para>402 403 315 </sect3> 404 316 … … 498 410 499 411 <para> 500 If you updated to address vulnerabilities, you can look at <filename501 class="directory">/sys/devices/system/cpu/vulnerabilities/</filename>502 to see what is nowreported.412 If you updated to address vulnerabilities, you can look at the 413 output of the <command>lscpu</command> command to see what is now 414 reported. 503 415 </para> 504 416 505 417 <para> 506 418 The places and times where early loading happens are very different 507 in AMD and Intel machines. First, an old example of an Intel (Skylake) with early loading: 508 </para> 509 510 <screen><literal>[ 0.000000] microcode: microcode updated early to revision 0xea, date = 2021-01-25 511 [ 0.000000] Linux version 5.12.8 (lfs@leshp) (gcc (GCC) 11.1.0, 512 GNU ld (GNU Binutils) 2.36.1) #2 SMP PREEMPT Fri Jun 4 01:25:02 BST 2021 513 [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.12.8-sda11 root=/dev/sda11 ro 514 resume=/dev/sda10 515 [ 0.381420] microcode: sig=0x506e3, pf=0x2, revision=0xea 516 [ 0.381479] microcode: Microcode Update Driver: v2.2.</literal></screen> 419 in AMD and Intel machines. First, an example of an Intel (Icelake 420 mobile) with early loading: 421 </para> 422 423 <screen><literal>[ 0.000000] microcode: microcode updated early to revision 0xb0, date = 2022-03-09 424 [ 0.000000] Linux version 5.18.1 (xry111@xry111-X57S1) (gcc (GCC) 12.1.0, GNU ld (GNU Binutils) 2.38) #95 SMP PREEMPT_DYNAMIC Sun Jun 5 21:14:29 CST 2022 425 [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.18.1-lfs-r11.1-109-systemd root=/dev/nvme0n1p7 ro 426 [ 0.435085] microcode: sig=0x706e5, pf=0x80, revision=0xb0 427 [ 0.435197] microcode: Microcode Update Driver: v2.2.</literal></screen> 517 428 518 429
Note:
See TracChangeset
for help on using the changeset viewer.