Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
vicamo opened this issue Jun 10, 2020 · 101 comments
Open

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

vicamo opened this issue Jun 10, 2020 · 101 comments

Comments

@vicamo
Copy link

@vicamo vicamo commented Jun 10, 2020

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.

@andyhhp
Copy link

@andyhhp andyhhp commented Jun 10, 2020

The differences between 0xd6 and 0xdc were quite minimal, to work around an SGX issue.

Does disabling SGX in the BIOS work around the hang using 0xdc?

@eguaj
Copy link

@eguaj eguaj commented Jun 10, 2020

As requested by @vicamo, here is the output from lscpu:

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    2
Core(s) per socket:    2
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 78
Model name:            Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
Stepping:              3
CPU MHz:               700.042
CPU max MHz:           2800.0000
CPU min MHz:           400.0000
BogoMIPS:              4800.00
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              3072K
NUMA node0 CPU(s):     0-3
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 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 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 md_clear flush_l1d

It's on a Lenovo T460 laptop.

@eguaj
Copy link

@eguaj eguaj commented Jun 10, 2020

The differences between 0xd6 and 0xdc were quite minimal, to work around an SGX issue.

Does disabling SGX in the BIOS work around the hang using 0xdc?

Disabling SGX does not seems to help: SGX was initially on "Software controlled", so changed it to "Disabled", but laptop still hangs when booting the new initrd image.

@andyhhp
Copy link

@andyhhp andyhhp commented Jun 10, 2020

Thanks for testing. I think this needs Intel to investigate now

@pjssilva
Copy link

@pjssilva pjssilva commented Jun 10, 2020

Same thing on my system with a similar CPU. I had to uninstall the intel-microcode package to boot. here is the output of lscpu:

Arquitetura:                     x86_64
Modo(s) operacional da CPU:      32-bit, 64-bit
Ordem dos bytes:                 Little Endian
Address sizes:                   39 bits physical, 48 bits virtual
CPU(s):                          4
Lista de CPU(s) on-line:         0-3
Thread(s) per núcleo:            2
Núcleo(s) por soquete:           2
Soquete(s):                      1
Nó(s) de NUMA:                   1
ID de fornecedor:                GenuineIntel
Família da CPU:                  6
Modelo:                          78
Nome do modelo:                  Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz
Step:                            3
CPU MHz:                         500.006
CPU MHz máx.:                    3000,0000
CPU MHz mín.:                    400,0000
BogoMIPS:                        4999.90
Virtualização:                   VT-x
cache de L1d:                    64 KiB
cache de L1i:                    64 KiB
cache de L2:                     512 KiB
cache de L3:                     3 MiB
CPU(s) de nó0 NUMA:              0-3
Vulnerability Itlb multihit:     KVM: Mitigation: Split huge pages
Vulnerability L1tf:              Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable
Vulnerability Mds:               Mitigation; Clear CPU buffers; SMT vulnerable
Vulnerability Meltdown:          Mitigation; PTI
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Full generic retpoline, IBPB conditional, IBRS_FW, STIBP conditional, RSB filling
Vulnerability Srbds:             Vulnerable: No microcode
Vulnerability Tsx async abort:   Mitigation; Clear CPU buffers; SMT vulnerable
Opções:                          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 pn
                                 i 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 sti
                                 bp 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 m
                                 d_clear flush_l1d
``

@esyr-rh
Copy link
Contributor

@esyr-rh esyr-rh commented Jun 10, 2020

@pjssilva
Copy link

@pjssilva pjssilva commented Jun 10, 2020

I used the Ubuntu package intel-microcode (3.20200609.0ubuntu0.20.04.0). I don't have it in my system anymore to check out. From the description of the package in https://launchpad.net/ubuntu/+source/intel-microcode/3.20200609.0ubuntu0.20.04.0 I guess 0x00d6. Do you want me to reinstall it and check?

@esyr-rh
Copy link
Contributor

@esyr-rh esyr-rh commented Jun 10, 2020

@pjssilva
Copy link

@pjssilva pjssilva commented Jun 10, 2020

So it is 0xdc (I found the reference in the middle of the description). As I said I can test what ever you want. Just point me to the file and instructions on how to apply it without an Ubuntu package. Thanks!

@hmh
Copy link

@hmh hmh commented Jun 10, 2020

Did you also update the Linux kernel? It would be nice to know if the regression is related to the microcode update itself, or to the combination of the two...

@pjssilva
Copy link

@pjssilva pjssilva commented Jun 10, 2020

It looks from my /var/log/apt/history.log that it also update the linux-image package to 5.4.0-37. This is the kernel I am using right now, it did not need to uninstall it. I only uninstalled intel-microcode and its dependencies (meta packages that install the latest kernel and friends). Both were unattended upgrades (because they were marked as a security update).

@hmh
Copy link

@hmh hmh commented Jun 10, 2020

Would it trouble you too much to test the intel-microcode package with an older kernel? With an old kernel, the microcode enables SRDBS mitigation in transparent mode, it is supposed to "just work" even if it might end up being enabled in a configuration that does not need it...

This ensures the issue is not being caused by some bug in the new kernel code.

@hmh
Copy link

@hmh hmh commented Jun 10, 2020

If you do test with an older kernel, please look in /proc/cpuinfo to ensure you are indeed running microcode revision 0xdc, i.e. the new one for your processor.

@pjssilva
Copy link

@pjssilva pjssilva commented Jun 10, 2020

You mean try to use a mainline kernel? What version? I can use mainline PPA to do it easily. How do I install the Intel microcode without a deb package. Just point me to the docs, I can manage myself.

@esyr-rh
Copy link
Contributor

@esyr-rh esyr-rh commented Jun 10, 2020

@hmh
Copy link

@hmh hmh commented Jun 10, 2020

@pjssilva: no, please use any older Ubuntu kernel that works well in your machine for the purposes of this testing.

@hmh
Copy link

@hmh hmh commented Jun 10, 2020

You can also use Debian's intel-microcode packages, they should be compatible enough with Ubuntu.

here:
http://deb.debian.org/debian/pool/non-free/i/intel-microcode/

You can use the ones without any "~deb" on their name.

@stevebeattie
Copy link

@stevebeattie stevebeattie commented Jun 10, 2020

@pjssilva FYI I'm preparing packages with a revert to version d6 for the 06-4e-03, they should be available for testing from https://launchpad.net/~sbeattie/+archive/ubuntu/lp1882890/ shortly. I would appreciate confirmation that they resolve the issue for you before publishing to the ubuntu archive.

Also, the previous ubuntu kernel in 20.04 is 5.4.0-33, should be available to install via sudo apt install linux-image-5.4.0-33-generic linux-modules-5.4.0-33-generic linux-modules-extra-5.4.0-33-generic linux-headers-5.4.0-33-generic.

@stevebeattie
Copy link

@stevebeattie stevebeattie commented Jun 10, 2020

Also, as a datapoint, we did successfully test the combintation of the 0xdc microcode + a srbds aware kernel on a system with an i5-6200U before publishing the 20200609 update.

@pjssilva
Copy link

@pjssilva pjssilva commented Jun 10, 2020

I am in the middle of my testing spree. What I learned so far:

0xd6 seems to work always.

As for 0xda:

With 5.4.0-37-generic: it fails a lot, but not always. I managed to boot into gnome after booting first in rescue mode (to see if the right). Some time it boots OK, but most time not. It might be easier to boot after a full shutdown (instead of a reboot).

With 5.4.0-33-generic: it seems to fail less, but it fails. Usually stuck after "loading initial ramdisk" (or somthing like this). I have the feeling that it does not fail if I do a full shutdown first. I will try that now (3 ful lshutdowns in a row).

@pjssilva
Copy link

@pjssilva pjssilva commented Jun 10, 2020

0xda did not pass the 3 cold boot test with 5.4.0-33-generic. So I can say that boot hangs with both 5.4.0-33 and 5.0.4-37 hot and cold boots. I don't see a pattern.

@stevebeattie I will try the packages in your ppa now. I will let you know what I find out.

@Malizor
Copy link

@Malizor Malizor commented Jun 10, 2020

Hi,

Same issue here, and I confirm the fix/rollback proposed by @stevebeattie does solve the problem.

My hardware:
Thinkpad T460S with i5-6200U
microcode: sig=0x406e3, pf=0x80, revision=0xd6
Running Ubuntu 20.04 (when the original microcode was installed, boot hanged regardless of the previous Kernel I tried)

@esyr-rh
Copy link
Contributor

@esyr-rh esyr-rh commented Jun 10, 2020

@pjssilva
Copy link

@pjssilva pjssilva commented Jun 10, 2020

@stevebeattie, as @Malizor I confirm that your package solves the problem.

@hmh
Copy link

@hmh hmh commented Jun 10, 2020

Well, looks like we (distros) will be forced to (re-)publish the security fix without 06-4e-03 :-(

@hmh
Copy link

@hmh hmh commented Jun 11, 2020

Just noticed 0x506e3 might have the same problem, but we got no reports (either positive or negative) thus far.

@rokezu
Copy link

@rokezu rokezu commented Jun 11, 2020

Just wanted to leave a report that on an Asus UX305-CA with an Intel Core m3-6y30 (sig=0x406e3), using Arch Linux and after just updating intel-ucode package, the system will refuse to boot, I had to edit the grub entry at boot time to remove the intel-ucode line from initrd and it boots again. Made a full system upgrade running 5.6.15-arch1-1 kernel. This seems like a QA issue at Intel?

@mirekingr
Copy link

@mirekingr mirekingr commented Jun 11, 2020

Same issue here, boot freezes on Ubuntu 20.04/focal

Dell Latitude 5591,
Intel Core i7-8850H, sig=0x000906ea
intel-microcode_3.20200609.0ubuntu0.20.04.2

@esyr-rh
Copy link
Contributor

@esyr-rh esyr-rh commented Jun 11, 2020

@JanZerebecki
Copy link

@JanZerebecki JanZerebecki commented Dec 18, 2020

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
Copy link

@hmh hmh commented Dec 22, 2020

@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
Copy link

@gerl1ng gerl1ng commented Dec 23, 2020

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

This comment has been minimized.

@hmh
Copy link

@hmh hmh commented Dec 27, 2020

@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
Copy link

@dbischof90 dbischof90 commented Dec 28, 2020

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
Copy link

@ZerBea ZerBea commented Jan 8, 2021

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
Copy link

@Christian-Git01 Christian-Git01 commented Jan 15, 2021

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
Copy link

@whpenner whpenner commented Jan 15, 2021

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
Copy link

@ZerBea ZerBea commented Jan 16, 2021

@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
Copy link

@Christian-Git01 Christian-Git01 commented Jan 17, 2021

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
Copy link

@dimadeush dimadeush commented Jan 18, 2021

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
Copy link

@fdutheil fdutheil commented Jan 18, 2021

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
Copy link

@dimadeush dimadeush commented Jan 18, 2021

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
Copy link

@hmh hmh commented Jan 18, 2021

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
Copy link

@hmh hmh commented Jan 18, 2021

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
Copy link

@dbischof90 dbischof90 commented Jan 19, 2021

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

@hmh
Copy link

@hmh hmh commented Jan 19, 2021

@dbischof90: yes.

@naitoshedo
Copy link

@naitoshedo naitoshedo commented Jan 21, 2021

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
Copy link

@ZerBea ZerBea commented Jan 21, 2021

@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
Copy link
Contributor

@esyr-rh esyr-rh commented Jun 8, 2021

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
Copy link

@Shados Shados commented Jun 9, 2021

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

@whpenner
Copy link

@whpenner whpenner commented Jun 9, 2021

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
Copy link

@fdutheil fdutheil commented Jun 15, 2021

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
Copy link

@JanZerebecki JanZerebecki commented Jun 15, 2021

Like in #31 (comment) 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
Copy link
Contributor

@esyr-rh esyr-rh commented Jun 15, 2021

@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
Copy link
Contributor

@esyr-rh esyr-rh commented Jun 17, 2021

@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
Copy link

@hmh hmh commented Jun 23, 2021

@whpenner, could you confirm if the latest revision (0xea) is supposed to work around the problem stated in #31 (comment) ?

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
Copy link

@whpenner whpenner commented Jul 8, 2021

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.

@hmh
Copy link

@hmh hmh commented Jul 8, 2021

Thank you. Most Linux distros do exactly that: update directly from BIOS to latest MCU (via an early update), that's why we request a reboot to apply the microcode updates.

It is important data for anyone doing late loads, though. Thank you for this information

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests