Hi, i have an notebook with intel core-m7 cpu https://ark.intel.com/content/www/us/en/ark/products/88199/intel-core-m7-6y75-processor-4m-cache-up-to-3-10-ghz.html It suddenly stopped booting when i updated the kernel which made little sense given the circumstances. i tracked the issue down to the built-in intel cpu microcode, in my case CONFIG_EXTRA_FIRMWARE="intel-ucode/06-4e-03" CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" Apparently, between my kernel update schedule, the file had changed on my filesystem, and ever since even older kernels wouldnt boot anymore when built with the microcode binary included. I checked the file from my file system against https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/master/intel-ucode/06-4e-03 and noticed they differ. [chef@ux305 ~]$ iucode_tool -l /tmp/06-4e-03 microcode bundle 1: /tmp/06-4e-03 selected microcodes: 001/001: sig 0x000406e3, pf_mask 0xc0, 2019-10-03, rev 0x00d6, size 101376 [chef@ux305 ~]$ iucode_tool -l /lib/firmware/intel-ucode/06-4e-03 microcode bundle 1: /lib/firmware/intel-ucode/06-4e-03 selected microcodes: 001/001: sig 0x000406e3, pf_mask 0xc0, 2020-01-09, rev 0x00da, size 104448 Without further investigation i rebuilt my kernel pointing to the file from github instead from the intel-microcode package and it sure enough boots again. Maybe i just did something wrong, but i have been using the intel-microcode package in this way for something like 3 years and this one really tripped me bad. I tried booting with efi stub directly or via refind, both wouldnt work. A boot with kexec worked, though.
It's not clear from the diff what's the working file for you. I assume your system has problems with *latest* MCU 2020-01-09, rev 0x00da. Is that correct?
AAAAAH, I've been banging my head on my desk a few dozens of times trying to spot what was wrong with this microcode which prevent my laptop to boot. It has a CPU with same signature as yours, Heiko (https://ark.intel.com/content/www/us/en/ark/products/88192/intel-core-i7-6600u-processor-4m-cache-up-to-3-40-ghz.html): $ iucode_tool -S -l /lib/firmware/intel-ucode/* iucode_tool: system has processor(s) with signature 0x000406e3 microcode bundle 1: /lib/firmware/intel-ucode/06-4e-01 microcode bundle 2: /lib/firmware/intel-ucode/06-4e-02 microcode bundle 3: /lib/firmware/intel-ucode/06-4e-03 microcode bundle 4: /lib/firmware/intel-ucode/06-4e-08 selected microcodes: 001/001: sig 0x000406e1, pf_mask 0xf2, 2014-08-06, rev 0x0016, size 80896 001/002: sig 0x000406e1, pf_mask 0x80, 2014-11-11, rev 0x0020, size 81920 002/001: sig 0x000406e2, pf_mask 0xf2, 2014-11-05, rev 0x000a, size 79872 002/002: sig 0x000406e2, pf_mask 0xc0, 2015-05-21, rev 0x002c, size 86016 003/001: sig 0x000406e3, pf_mask 0xc0, 2020-01-09, rev 0x00da, size 104448 004/001: sig 0x000406e8, pf_mask 0x80, 2016-04-14, rev 0x0026, size 94208 I'm not sure that sys-firmware/intel-microcode-20200508_p20200508 is the only version affected. MCU rev 0x00da must have been in there for a while. MCU wasn't loaded on my system before because of having USE initramfs only recently enabled (my bad) + long time since last stable sys-kernel/gentoo-sources update, which means Grub2 didn't picked intel-uc.img until a couple weeks back. I tested loading the MCU by getting it "inside the kernel" like Heiko does instead of loading it by intel-uc.img, but same issue occurred. So I concluded the way I load the MCU is not relevant. On a side note, I updated laptop's BIOS, and default MC is now revision=0xd6 (microcode: sig=0x406e3, pf=0x80, revision=0xd6).
Sorry for not making that clear. >> I assume your system has problems with *latest* MCU 2020-01-09, rev 0x00da. >> Is that correct? Yes, that is correct. @El Goretto: Yeah, the problems started with the intel-microcode package version released on 2020-04-29 i think. My last successful "old" kernel was built on April 1st, and i noticed the problem on May 1st for the first time. Some more info that may or may not help: The problematic kernel i built with revision 0x00da actually did update the processor microcode to 0x00da when booted with kexec (the only possible way i found) as per dmesg. When i boot with my workaround obviously i'm at 0x00d6 now, and doing echo 1 > /sys/devices/system/cpu/microcode/reload after boot does nothing. The 0x00da version is still installed in /lib/firmware/intel-ucode.
Not really helpful, but I did `echo 1 > /sys/devices/system/cpu/microcode/reload` and I got this: microcode: updated to revision 0xda, date = 2020-01-09 x86/CPU: CPU features have changed after loading microcode, but might not take effect. x86/CPU: Please consider either early loading through initrd/built-in or a potential BIOS update. microcode: Reload completed, microcode revision: 0xda Running a MC that doesn't boot may not be safe, so rebooting right now :)
I have had this problem for a while. The boot hangs after loading the kernel, when loading /boot/intel-uc.img. I can however press 'e' in grub and edit out the intel-uc.img option to proceed with the boot, but without updated microcode. I have since replaced /boot/intel-uc.img with an older version that works. The latest version that works for me is 20191115_p20200209. I have tried 20191115_p20200429 and 20200508_p20200508 which both fails. I have not tried 20200520_p20200601 yet, but will do so when I get the chance. Vendor ID: GenuineIntel CPU family: 6 Model: 78 Model name: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
The bug is confirmed upstream: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31 I personally have been unable to boot (hangs at Loading kernel, any new kernel using the new Intel microcode version 06-4e-03) The only kernel that runs normally is one I have from 3 months ago, with the Intel microcode blob builtin. (revision=0xd6, date=2019-10-03, 06-4e-03). Which is the same suggested to be used by upstream right now. This version needs to be reverted asap back to portage tree and the new one hard-masked until it's fixed by upstream. Please change the status to confirmed.
Hi, I just installed sys-firmware/intel-microcode-20200609_p20200601 which now contains MC rev 0x00dc for "our CPUs". Same issue than with rev 0x00da.
As a compromise, Debian's update excludes Skylake-U/Y's microcode. It's the best thing that one can do for now. https://www.debian.org/security/2020/dsa-4701
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c1d8ba62ab0bcbea3133864a8dfce246406f181c commit c1d8ba62ab0bcbea3133864a8dfce246406f181c Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2020-06-14 22:09:40 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2020-06-14 22:11:50 +0000 sys-firmware/intel-microcode: rev bump - Mask sig 0x000406e3, pf_mask 0xc0, revision=0xd6 [Link 1] - Mask sig 0x000406e3, pf_mask 0xc0, revision=0xda [Bug 722768] This will basically downgrade microcode for 0x000406e3 back to rev 0x00d6 from 2019-10-03. Link 1: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31 Closes: https://bugs.gentoo.org/722768 Package-Manager: Portage-2.3.100, Repoman-2.3.22 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> sys-firmware/intel-microcode/Manifest | 1 + .../intel-microcode-20200609_p20200601-r1.ebuild | 259 +++++++++++++++++++++ 2 files changed, 260 insertions(+)
