Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Christian Hesse (eworm)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:

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
Comment by Javier (je-vv) - Friday, 12 June 2020, 07:20 GMT
Forgot to include that the initrd resulting entry on grub.cfg is:

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, :)
Comment by Dimitris Chrysostomou (DimitrisC) - Friday, 12 June 2020, 09:46 GMT
I have the same problem. Downgrading or completely removing the intel-ucode 20200609-1 package solves the issue.

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.
Comment by Johannes Truschnigg (colo) - Friday, 12 June 2020, 12:35 GMT
Same problem for me when booting my machine with Linux 5.7.2-arch1-1 with the following kernel command line (booting via systemd-boot in UEFI mode):

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.
Comment by loqs (loqs) - Friday, 12 June 2020, 12:48 GMT Comment by Christian Hesse (eworm) - Friday, 12 June 2020, 17:48 GMT
Please have a look at:

journalctl -b | grep microcode

Your CPU signature is 0x406e3?
Comment by Christian Hesse (eworm) - Friday, 12 June 2020, 18:02 GMT
Anybody wants to try intel-ucode 20200609-2 from testing?
Comment by Jouke Witteveen (jouke) - Friday, 12 June 2020, 18:16 GMT
20200609-2 fixes the problem for me :-)!
Comment by Christian Hesse (eworm) - Friday, 12 June 2020, 18:22 GMT
Let's hope Intel will fix this properly any time soon.
Comment by Andrea Amorosi (AndreaA) - Monday, 15 June 2020, 19:09 GMT
  • Field changed: Percent Complete (100% → 0%)
My laptop has the same issue also with intel-ucode 20200609-2. I have to revert to 20200520-1 to solve the issue.
My cpu is an i7-6700hq.
Comment by loqs (loqs) - Monday, 15 June 2020, 19:41 GMT
@AndreaA what is the CPU signature?

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
Comment by Christian Hesse (eworm) - Monday, 15 June 2020, 19:50 GMT
If you see this with intel-ucode 20200609-2 it's a different issue. Please open a new bug describing your issue and append output of `lscpu`.

Loading...