Open vicamo opened 4 years ago
Intel's microcode issue is still alive for laptops Dell Latitude (my model 5591). Dell has not released firmware updates for this range yet, perhaps beta testing on other models :smile:
06-4e-03/06-5e-03 microcode has been updated to revision 0xe2 in microcode-20201110 release, does the newer microcode revision help?
I can confirm the latest microcode-20201110 boots just fine for me :slightly_smiling_face:
Just to note, the issue on Dell Latitude 5491/5591 got fixed earlier by a relevant firmware update 1.13.1.
This package contains the Dell system BIOS update. BIOS is a firmware package that is embedded on a small memory chip on the system board. It controls the keyboard, monitor, disk drives, and other devices. This update addresses the Intel Security Advisories INTEL-SA-00295, INTEL-SA-00320, INTEL-SA-00322, and INTEL-SA-00329. A security advisory is a statement when a security vulnerability impacts a product, and a remedy is available for the vulnerability. This update addresses the Intel Technical Advisory INTEL-TA-00404.
On Wed, Nov 11, 2020 at 01:49:41AM -0800, Mirek Ingr wrote:
I can confirm the latest microcode-20201110 boots just fine for me :slightly_smiling_face:
Just to note, the issue on Dell Latitude 5491/5591 got fixed earlier by a relevant firmware update 1.13.1.
Since the issue is within OS-based microcode update (per [1]), may I ask to confirm that the update has been actually performed during OS boot?
[1] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31#issuecomment-644885826
The package is definitely installed but not sure the actual microcode was updated.
Here are outputs of relevant commands if it helps:
$ apt-show-versions intel-microcode
intel-microcode:amd64/focal-security 3.20201110.0ubuntu0.20.04.2 uptodate
$ iucode-tool -Sv
iucode-tool: system has processor(s) with signature 0x000906ea
iucode-tool: assuming all processors have the same type, family and model
$ dmesg | grep microcode
[ 0.000000] microcode: microcode updated early to revision 0xde, date = 2020-05-25
[ 0.812573] microcode: sig=0x906ea, pf=0x20, revision=0xde
[ 0.812828] microcode: Microcode Update Driver: v2.2.
On Thu, Nov 12, 2020 at 12:16:22AM -0800, Mirek Ingr wrote:
$ dmesg | grep microcode [ 0.000000] microcode: microcode updated early to revision 0xde, date = 2020-05-25
This line tells that the microcode has been indeed updated during early boot, thank you.
So, this nasty regression has been fixed (and thus likely the same regression on 0x506e3 / 06-5e-03 was fixed as well). Good !
Err, I may be wrong but it seems mirekingr's CPU's signature is not the one discussed here. And that has already been stated. Go away mirekingr, shooo! :P
Anyway, on my laptop (sig=0x406e3, with 0xd6 revision embedded in BIOS) which was affected by the nasty 0xda version issue, microcode revision 0xe2 loads fine when OS boots up: microcode: microcode updated early to revision 0xe2, date = 2020-07-14
For the record, I missed it but an "already updated version" (regarding the problematic 0xda) 0xe0 was already present on my system and was fine too: microcode: microcode updated early to revision 0xe0, date = 2020-06-24
On Fri, Nov 13, 2020 at 05:19:50AM -0800, Florent Dutheil wrote:
Err, I may be wrong but it seems mirekingr's CPU's signature is not the one discussed here. And that has already been stated. Go away mirekingr, shooo! :P
Ugh, you're right, I've overlooked that.
mirekingr, Bugs #24, #33, #35 are more relevant to 06-[89]e-0* CPUIDs.
Anyway, on my laptop (sig=0x406e3) which was affetect by the nasty 0xda version issue, microcode revision 0xe2 loads fine when OS boots up:
microcode: microcode updated early to revision 0xe2, date = 2020-07-14
For the record, I missed it but an "already updated version" (regarding the problematic 0xda) 0xe0 was already present on my system and was fine too.
Thank you for the confirmation.
Early microcode update to revision 0xe2 still hangs on the following system with CPUD 0x406e3:
bios_date 07/22/2015
bios_vendor Intel Corporation
bios_version SKLSE2R1.R00.B093.B02.1507222151
board_asset_tag Base Board Asset Tag
board_name Skylake Y LPDDR3 RVP3
board_serial 1
board_vendor Intel Corp.
board_version 2
chassis_asset_tag Un-Supported
chassis_serial serial#
chassis_type 9
chassis_vendor Intel Corporation
chassis_version 0.1
product_family Skylake Client System
product_name Skylake Client platform
product_serial System Serial Number
product_sku System SKUNumber
product_uuid 0ce81334-3596-1334-e80c-96353413e80c
product_version 0.1
sys_vendor Intel Corporation
Firmware-supplied microcode revision is 0x2d. Late updates to both 0xdc and 0xe2 seem to work, though.
So, it works on some platforms where it used to fail, but still hangs on other platforms.
It is really strange that late updates would work, though. It suggests it is related to features/MSR we only touch when they're already available (due to an early update) during kernel init.
@esyr-rh, is it worth trying to test the early update case with a loader that is known to properly align the early microcode update? dracut doesn't know how to do that last time I checked, but "iucode_tool --write-earlyfw" does.
Without this trick, early updates for the BSP (and only for the BSP) will be 4-byte aligned but not 16-byte aligned. It has not been a problem since the Centrino Pentium M, but Intel has not removed the 16-byte alignment requirement from the relevant Intel SDM section either.
EDIT: confirmed to not be relevant to the issue.
Now, if anyone in Ubuntu or Debian still sees this issue, then it cannot be the alignment, as Ubuntu does align it to 16-bytes using iucode-tool. And it is unlikely to be that alignment, anyway.
@fdutheil, could you tell us what distro you use, since you were affected before by the reverted microcode update, but now it works with the new microcode update?
@hmh:
[ 0.000000] microcode: microcode updated early to revision 0xe2, date = 2020-07-14
[ 2.054752] microcode: sig=0x406e3, pf=0x80, revision=0xe2
[ 2.055387] microcode: Microcode Update Driver: v2.2.
[28843.269173] microcode: sig=0x406e3, pf=0x80, revision=0xd6
[28843.272250] microcode: updated to revision 0xe2, date = 2020-07-14
[28843.273634] microcode: sig=0x406e3, pf=0x80, revision=0xe2
System Information
Processor Information
Base Board Information
BIOS Information
Well, that means microcode alignment during BSP early update has nothing to do with these issues. As expected, really, but since it is one of the differences -- the other being whatever codepaths (including in the microcode) related to new functionality that get enabled by Linux only on early loading -- it is good to know for sure.
my computer wouldn't boot with microcode-20200609. Now my computer won't boot with microcode-20201110.
I am on ubuntu 20.10 and i have a lenovo yoga 710 computer
does this relate to this issue, or is it another issue? what can I do to troubleshoot this issue?
my computer wouldn't boot with microcode-20200609. Now my computer won't boot with microcode-20201110.
I am on ubuntu 20.10 and i have a lenovo yoga 710 computer
does this relate to this issue, or is it another issue? what can I do to troubleshoot this issue?
Please create a new issue with all the details to the used processor, and attach the Linux logs with the working microcode, so it’s clear what firmware version is used.. I recommend to also report an issue in the Ubuntu bug tracker (and possibly Lenovo).
Linux debian 5.9.0-4-amd64 #1 SMP Debian 5.9.11-1
Fails on early boot: intel-microcode_3.20201110.1_amd64.deb
according to release notes that is revision=0xe2
Works on early boot: kernel: microcode: sig=0x406e3, pf=0x80, revision=0xd6 from: intel-microcode_3.20200616.1~deb10u1_amd64.deb
revert it again?
Linux debian 5.9.0-4-amd64 #1 SMP Debian 5.9.11-1
Fails on early boot: intel-microcode_3.20201110.1_amd64.deb according to release notes that is revision=0xe2Works on early boot: kernel: microcode: sig=0x406e3, pf=0x80, revision=0xd6 from: intel-microcode_3.20200616.1~deb10u1_amd64.deb
What device is this on? If on a laptop, can you please verify, it’s independent from the power cable being plugged in? Do you have any log messages? Does botting with nosmp
work?
Yes this is a laptop, a tuxedo/schenker with a i7-6500U. Others mentioned this cpu working for them with the new rev 0xe2 microcode. But I never applied a BIOS update, so that may make a difference (the first applied microcode is different, then).
No, after grub says it loaded the initrd the grub screen remains as is, so no log messages from the failing boot. After it fails I need to retry a few times switching off and booting with the working microcode for it to work.
I haven't tried with nosmp. Doesn't it showing no printed lines from Linux mean it failed long before smp bringup, so that can't make a difference? I.e. it fails before it could print its first line with "microcode updated early".
1. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1883065 2. https://lkml.org/lkml/2020/6/11/474
These reports show a failure later during boot and only with power unplugged. My failures were earlier (before the first line from Linux printed) and with the power cable plugged in. I didn't test without power cable plugged in.
@JanZerebecki:
Linux debian 5.9.0-4-amd64 #1 SMP Debian 5.9.11-1
Fails on early boot: intel-microcode_3.20201110.1_amd64.deb according to release notes that is revision=0xe2Works on early boot: kernel: microcode: sig=0x406e3, pf=0x80, revision=0xd6
What is the version of the microcode present in your BIOS (i.e. which microcode is active when you do not have any intel-microcode packages installed )?
Having the same boot problems for my Lenovo T460s here (i5-6200u). Without the intel-ucode it boots fine.
Ucode package installed is intel-ucode 20201118-1 for Arch.
I have microcode 0x74 active when no dedicated ucode package is loaded.
[root@laptop ~]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 78
model name : Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
stepping : 3
microcode : 0x74
cpu MHz : 500.040
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
vmx flags : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple pml
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds
bogomips : 4801.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
...
[root@laptop ~]# dmesg |grep microcode
[ 0.055286] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0xb2 (or later)
[ 0.174780] SRBDS: Vulnerable: No microcode
[ 0.174781] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[ 1.786062] microcode: sig=0x406e3, pf=0x80, revision=0x74
[ 1.786215] microcode: Microcode Update Driver: v2.2.
Installed it on my desktop as well. It works there with the i7-7700 CPU
@pc ~]$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 158
model name : Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz
stepping : 9
microcode : 0xde
cpu MHz : 800.078
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d
vmx flags : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple shadow_vmcs pml ept_mode_based_exec
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds
bogomips : 7202.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
@pc ~]$ dmesg |grep microcode
[Dec23 17:54] microcode: microcode updated early to revision 0xde, date = 2020-05-26
[ +0.000613] microcode: sig=0x906e9, pf=0x2, revision=0xde
[ +0.000173] microcode: Microcode Update Driver: v2.2.
@gerl1ng: this bug report is not about the i7-7700, so it would be best to hide/remove your comment about it: it just confuse things.
As for your Lenovo T460 with a 0x406e3 processor on rev 0x74 that cannot be early-updated to the current microcode revision, that is a relevant data point. Thank you.
Having the same boot problems for my Lenovo T460s here (i5-6200u). Without the intel-ucode it boots fine.
Ucode package installed is intel-ucode 20201118-1 for Arch.
I have microcode 0x74 active when no dedicated ucode package is loaded.
[root@laptop ~]# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 78 model name : Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz stepping : 3 microcode : 0x74 cpu MHz : 500.040 cache size : 3072 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp vmx flags : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple pml bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds bogomips : 4801.00 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: ... [root@laptop ~]# dmesg |grep microcode [ 0.055286] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0xb2 (or later) [ 0.174780] SRBDS: Vulnerable: No microcode [ 0.174781] MDS: Vulnerable: Clear CPU buffers attempted, no microcode [ 1.786062] microcode: sig=0x406e3, pf=0x80, revision=0x74 [ 1.786215] microcode: Microcode Update Driver: v2.2.
I have the same problem on the current Arch Linux install on the same Laptop, my CPU is i7-6600U, microcode 0x74. Uninstalling intel-ucode restores bootability for now.
What can I do?
Same issue here, too. System doesn't boot running latest intel-ucode 20201118-1. Looks like the issue is still present. ASUS X555U notebook / i5-6200U $ uname -r 5.10.5-arch1-1 Removing intel-ucode solved it, but that is a quick and dirty solution.
I also cannot boot when intel-ucode is installed. I am on a Dell Latitude 7400 with i7-8665U CPU and 5.10.70-arch-1. Are there any news on this problem?
Problem Statement: Intel has identified an issue when performing OS patch loading of MCU version 0xE2 on SKL R0 (506e3) and SKL D0 (406e3) systems when the existing Microcode Update (MCU) version is earlier than 0x80
Issue description: When an OS loads the latest MCU patches on SKL R0 (506e3) and SKL D0 (406e3), may lead to unexpected failures in the following conditions: • The system has a BIOS containing MCU version earlier than 0x80 (MCU < 0x80) • The user tries to load via OS load mechanism a new MCU version 0xD8 or greater
Workaround: Update affected systems to a BIOS containing MCU version 0x80 or greater.
@whpenner Unfortunately not the best suggestion for a workaround. We all know about the "update policy" of the manufacturers. On most of their products EOS is reached very soon (e.g. my ASUS received the last BIOS update in 2019).
Problem Statement: Intel has identified an issue when performing OS patch loading of MCU version 0xE2 on SKL R0 (506e3) and SKL D0 (406e3) systems when the existing Microcode Update (MCU) version is earlier than 0x80
Issue description: When an OS loads the latest MCU patches on SKL R0 (506e3) and SKL D0 (406e3), may lead to unexpected failures in the following conditions: • The system has a BIOS containing MCU version earlier than 0x80 (MCU < 0x80) • The user tries to load via OS load mechanism a new MCU version 0xD8 or greater
Workaround: Update affected systems to a BIOS containing MCU version 0x80 or greater.
Thanks! That worked for me.
intel core i9 also has a problem, I'm using latest BIOS version. More info about intel microcode bug here - https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1911893.
intel core i9 also has a problem, I'm using latest BIOS version. More info about intel microcode bug here - https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1911893.
Please verify that your CPU has the signature corresponding to the issue discussed here (cannot find this info in your comment nor through the launchpad link). If that's a different signature, please open another dedicated issue.
@whpenner: nice finding. Can you give a source?
intel core i9 also has a problem, I'm using latest BIOS version. More info about intel microcode bug here - https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1911893.
Please verify that your CPU has the signature corresponding to the issue discussed here (cannot find this info in your comment nor through the launchpad link). If that's a different signature, please open another dedicated issue.
Please find all info here - https://forums.linuxmint.com/viewtopic.php?f=49&t=339625&sid=bdf869985cc73de93fc77e1ce330aa29
intel core i9 also has a problem, I'm using latest BIOS version. More info about intel microcode bug here - https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1911893.
That core i9 is model 158, completely unrelated to this issue.
Problem Statement: Intel has identified an issue when performing OS patch loading of MCU version 0xE2 on SKL R0 (506e3) and SKL D0 (406e3) systems when the existing Microcode Update (MCU) version is earlier than 0x80
Issue description: When an OS loads the latest MCU patches on SKL R0 (506e3) and SKL D0 (406e3), may lead to unexpected failures in the following conditions: • The system has a BIOS containing MCU version earlier than 0x80 (MCU < 0x80) • The user tries to load via OS load mechanism a new MCU version 0xD8 or greater
Workaround: Update affected systems to a BIOS containing MCU version 0x80 or greater.
@whpenner: thanks, however we do need some extra information to act upon:
If the answer to (1) above is "yes, now that Intel know where the problem is, there is a way to avoid it and Intel will update the microcode to avoid the issue", then we (distros) can remove the problematic update meanwhile, without the need for kernel patches, etc...
So a recommended fix would be to update BIOS if possible and then attempt to use the new microcode package?
@dbischof90: yes.
If a bios update is not available from the motherboard manufacturer, I would highly recommend looking into UBU and patch the microcode into a bios update directly... Good luck expecting support from motherboard manufacturers... Last bios update for my server board was 4 years ago at this point (Thanks SuperMicro)
@naitoshedo thanks for pointing me in that direction. Now everything's fine:
$ grep 'stepping\|model\|microcode' /proc/cpuinfo
model : 78
model name : Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
stepping : 3
microcode : 0xe2
model : 78
model name : Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
stepping : 3
microcode : 0xe2
model : 78
model name : Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
stepping : 3
microcode : 0xe2
model : 78
model name : Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
stepping : 3
microcode : 0xe2
New revision 0xea of 06-4e-03/06-5e-03 microcode files has been published as part of microcode-20210608 release, it may be worth trying out.
The 0xea
revision in microcode-20210608 boots OK on my sig=0x406e3
device (an Asus UX305CA with an m3-6Y30).
The above should be resolved with MCU revision ids of 0xe2 or higher for CPUID 406e3 (06-4e-03) and 506e3 (06-5e-03). MCUs released yesterday included revision id 0xea for these products.
As already stated, the issue was fixed on a previous MCU version for my hardware (see previous comments), this 0xea
version boots fine too here:
$ dmesg |grep micro
[ 0.000000] microcode: microcode updated early to revision 0xea, date = 2021-01-25
[ 1.822001] microcode: sig=0x406e3, pf=0x80, revision=0xea
[ 1.822896] microcode: Microcode Update Driver: v2.2.
Like in https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31#issuecomment-747807263 the latest release also fails in the same way (no change to the bios):
Linux debian 5.10.0-7-amd64 #1 SMP Debian 5.10.40-1
intel-microcode_3.20210608.1_amd64.deb
according to release notes that is version=0xea
@JanZerebecki what microcode revision is reported when the kernel is loaded with dis_ucode_ldr
parameter? Does early update to 0xd6
plus late update to 0xea
work?
@jirireischig may I ask to check if 0xe2/0xea microcode revision helps you (in case you still have the problematic (<0x80) microcode revision applied by firmware/BIOS), by chance?
@whpenner, could you confirm if the latest revision (0xea) is supposed to work around the problem stated in https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31#issuecomment-761228960 ?
It would be really nice to be able to ship the microcode update without worrying about severely outdated BIOSes that cannot be fixed due to the usual motherboard-vendor-won't-issue-updated-firmware + EOL issues.
Yes, this should resolve the issue called out in #31. This MCU was updated to work with either the older MCU (older than revision ID 0x80) and the newer MCUs. I would not recommend an early load of an affected MCU and then load of the latest MCU. The results may be unpredictable. Updating from a BIOS loaded MCU to the latest MCU directly is the recommended method.
Per reports from https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1882890,
sig 0x000406e3, pf_mask 0xc0, 2020-04-27, rev 0x00dc, size 104448
hangs user's system in a similar way as #24 does but to different cpu. It's also reported the same file of a previous revisionmicrocode: sig=0x406e3, pf=0x80, revision=0xd6
works just fine.