search

intel / Intel-Linux-Processor-Microcode-Data-Files

Other
637 stars 70 forks source link

microcode-20200609 Release, at least 06-4e-03, hangs user's system #31

Open vicamo opened 4 years ago

vicamo commented 4 years ago

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 revision microcode: sig=0x406e3, pf=0x80, revision=0xd6 works just fine.

mirekingr commented 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:

esyr-rh commented 3 years ago

06-4e-03/06-5e-03 microcode has been updated to revision 0xe2 in microcode-20201110 release, does the newer microcode revision help?

mirekingr commented 3 years ago

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.

esyr-rh commented 3 years ago

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

mirekingr commented 3 years ago

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.
esyr-rh commented 3 years ago

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.

hmh commented 3 years ago

So, this nasty regression has been fixed (and thus likely the same regression on 0x506e3 / 06-5e-03 was fixed as well). Good !

fdutheil commented 3 years ago

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

esyr-rh commented 3 years ago

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.

esyr-rh commented 3 years ago

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.

hmh commented 3 years ago

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.

hmh commented 3 years ago

@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.

hmh commented 3 years ago

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.

hmh commented 3 years ago

@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?

fdutheil commented 3 years ago

@hmh:

About the software

About the hardware

hmh commented 3 years ago

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.

tugboat-maguire commented 3 years ago

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?

paulmenzel commented 3 years ago

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).

JanZerebecki commented 3 years ago

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?

paulmenzel commented 3 years ago

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

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?

JanZerebecki commented 3 years ago

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".

JanZerebecki commented 3 years ago 
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.

hmh commented 3 years ago

@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=0xe2

Works 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 )?

gerl1ng commented 3 years ago

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.
gerl1ng commented 3 years ago

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.
hmh commented 3 years ago

@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.

dbischof90 commented 3 years ago

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?

ZerBea commented 3 years ago

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.

Christian-Git01 commented 3 years ago

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?

whpenner commented 3 years ago

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.

ZerBea commented 3 years ago

@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).

Christian-Git01 commented 3 years ago

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.

dimadeush commented 3 years ago

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.

fdutheil commented 3 years ago

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?

dimadeush commented 3 years ago

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

hmh commented 3 years ago

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.

hmh commented 3 years ago

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:

  1. Will Intel somehow be able to work around this issue in a future public update of this microcode ? If so, do you have any idea of when it will be out?
  2. If the answer to (1) above is "no, it is not possible", will Intel handle the required patches for the Linux microcode update driver to blacklist the unsupported updates, or do we need to do it ourselves? Because, well, a lot of vendors are not going to issue updates and a lot of users will not apply them anyway. So we need to avoid the lockups and we need to tell the user they need a firmware update if they require the fixes in the new microcode.

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...

dbischof90 commented 3 years ago

So a recommended fix would be to update BIOS if possible and then attempt to use the new microcode package?

hmh commented 3 years ago

@dbischof90: yes.

naitoshedo commented 3 years ago

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)

ZerBea commented 3 years ago

@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
esyr-rh commented 3 years ago

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.

Shados commented 3 years ago

The 0xea revision in microcode-20210608 boots OK on my sig=0x406e3 device (an Asus UX305CA with an m3-6Y30).

whpenner commented 3 years ago

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.

fdutheil commented 3 years ago

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.
JanZerebecki commented 3 years ago

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

esyr-rh commented 3 years ago

@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?

esyr-rh commented 3 years ago

@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?

hmh commented 3 years ago

@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.

whpenner commented 3 years ago

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.