Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#66978 - [intel-ucode] freede on boot with 20200609-1 (06-4e-03)
Attached to Project:
Arch Linux
Opened by Javier (je-vv) - Thursday, 11 June 2020, 20:43 GMT
Last edited by Christian Hesse (eworm) - Monday, 15 June 2020, 19:52 GMT
Opened by Javier (je-vv) - Thursday, 11 June 2020, 20:43 GMT
Last edited by Christian Hesse (eworm) - Monday, 15 June 2020, 19:52 GMT
|
DetailsDescription:
When upgrading intel-ucode from 20200520-1 to 20200609-1, and after a reboot, I get my laptop frozen on the initrd process, it never gets to the point of requesting me the password to decrypt the root FS (LVM on LUKS). My laptop is a "HP EliteBook 840 G3" with 4 cores "Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz". I'm using linux version 5.6.15.arch1-1, and by using the newer version 5.7.2.arch1-1 I get the same results. The only work around this issue is to revert back intel-ucode to version 20200520-1, which doesn't make the initrd to get frozen Additional info: * package version(s) intel-ucode 20200609-1 (prior 20200520-1 works just fine) * config and/or log files etc. /etc/mkinitcpio.conf MODULES=(i915) BINARIES=() FILES=() HOOKS=(base udev block autodetect modconf keyboard keymap encrypt lvm2 resume filesystems fsck) /etc/default/grub ... GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/m1/root resume_offset=34816 iommu=pt intel_iommu=on loglevel=3 quiet" GRUB_CMDLINE_LINUX="rootwait rootfstype=ext4 cryptdevice=UUID=a19b147d-c07a-4b69-98ae-de4c5a47687e:cryp-m1:allow-discards" ... * link to upstream bug report, if any Steps to reproduce: See description. |
This task depends upon
Closed by Christian Hesse (eworm)
Monday, 15 June 2020, 19:52 GMT
Reason for closing: Fixed
Additional comments about closing: intel-ucode 20200609-2
Monday, 15 June 2020, 19:52 GMT
Reason for closing: Fixed
Additional comments about closing: intel-ucode 20200609-2
initrd /intel-ucode.img /initramfs-linux.img
So, most likely the initramfs-linux.img is not even sourced, and the intel-ucode one is just getting stuck. Something else, is that on a different system, but still with intel cores, a Mintbox 2 mini-pc,with 2 cores "Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz", the issue is not present. Perhaps only on the newer cpus, i7-6600U, experience the issue.
A minor fix on the laptop with the issue, it has 2 cores, not 4 as originally stated, those 4 were hyper threads, :)
I think is related to this bug: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1882890
Seems a fix was released in Ubuntu. Don't know if Arch has something similar planned or if Intel should work on this.
initrd=\intel-ucode.img initrd=\initramfs-linux.img root=/dev/sda2 nmi_watchdog=0 rw
My CPU model name reads "Intel(R) Core(TM) m3-6Y30 CPU @ 0.90GHz"
Appending " dis_ucode_ldr" to the kernel command line fixes the problem (but doesn't load any ucode, so it's a temporary workaround at best) for me.
journalctl -b | grep microcode
Your CPU signature is 0x406e3?
My cpu is an i7-6700hq.
journalctl -b | grep microcode
0x206a7 [1], 0x40661 [2], 0x806eb [3] All have one report of 20200609 causing a boot failure.
[1] https://bbs.archlinux.org/viewtopic.php?pid=1910051#p1910051
[2] https://bbs.archlinux.org/viewtopic.php?pid=1910056#p1910056
[3] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/33