Arch Linux

Please read this before reporting a bug:

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!

FS#57511 - [linux] 4.15 hangs during boot with intel-ucode

Attached to Project: Arch Linux
Opened by Andrea Amorosi (AndreaA) - Wednesday, 14 February 2018, 20:33 GMT
Last edited by Jan Steffens (heftig) - Saturday, 17 February 2018, 18:57 GMT
Task Type Bug Report
Category Kernel
Status Assigned
Assigned To Tobias Powalowski (tpowa)
Jan Steffens (heftig)
Christian Hesse (eworm)
Architecture All
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 6
Private No


All the 4.15 kernels up to now released (at the moment 4.15.2-2) hang during boot on my asus 2752vx (intel i7-6700hq with nvidia 950m and optimus prime) if intel-ucode .img is passed as a parameter to initrd.

These are the lines in grub.cfg:
linux /vmlinuz-linux root=UUID=74296c4e-84df-4eda-87a1-09be9d8e114b rw pci=noaer nvidia-drm.modeset=1 initcall_debug no_console_suspend ignore_loglevel dyndbg="file suspend.c +p"
echo 'Caricamento ramdisk iniziale...'
initrd /intel-ucode.img /initramfs-linux.img

At boot time the system writes the 'Caricamento ramdisk iniziale...' on the screen and that line remains on the video, but the system is completely unresponsive and
adding the earlyprintk=efi,keep to the boot command I've discovered that kernels hang at the following line:

... x86: Booting SMP configuration ...

Adding acpi=off let the boot precess to proceed a bit and a lot of messages are displayed, but then it hangs again when the Xsystem and sddm should be called.

With the original kernel parameters (without acpi=off) and the initrd line modified in this way:
initrd /initramfs-linux.img
the system works perfectly.

Reverting to the previous intel-ucode version does not solve the issue.

Linux is installed on this pc since March 2016 and up to now it has worked correctly.

This task depends upon

Comment by Andrea Amorosi (AndreaA) - Wednesday, 14 February 2018, 22:55 GMT
The same happens with the newer Linux n752vx 4.15.3-1-ARCH #1 SMP PREEMPT Mon Feb 12 23:01:17 UTC 2018 x86_64 GNU/Linux
Comment by Denis Mayborodin (Dzen_Python) - Saturday, 17 February 2018, 11:39 GMT
Bug confirmed on fresh x86_64 Linux 4.15.3-2-ARCH (Aspire E5-571g-36mp laptop) - system NOT hangs on boot only when I've been deleted /boot/intel-ucode.img from my grub.cfg.
Comment by Andrea Amorosi (AndreaA) - Saturday, 17 February 2018, 17:43 GMT
I confirm it still happens with Linux n752vx 4.15.3-2-ARCH #1 SMP PREEMPT Thu Feb 15 00:13:49 UTC 2018 x86_64 GNU/Linux on my laptop
Comment by Jan Steffens (heftig) - Saturday, 17 February 2018, 18:57 GMT
Wasn't the 20180108 microcode update retracted because of issues? Maybe we should downgrade back to 20171117.
Comment by Andrea Amorosi (AndreaA) - Saturday, 17 February 2018, 19:20 GMT
I have a week ago already tried to revert to intel-ucode-20171117-1-any.pkg.tar.xz (with 4.15.1), but without success (it was a quick test, but rebooting the issue was still there so I upgraded again to the latest intel-ucode).
Please let me know if you want me to try to revert again intel-ucode with the 4.15.3 or to revert to an older intel-ucode package.
Comment by loqs (loqs) - Saturday, 17 February 2018, 19:33 GMT
4.15.2+ and 4.14.18+ have backports of a5b2966364538a0e68c9fa29bc0a3a1651799035 guarding against the issue with the 20180108 ucode
4.14.18+ not 4.14.8+
Comment by loqs (loqs) - Saturday, 17 February 2018, 20:58 GMT
Does it also happen with linux-lts?
Comment by Andrea Amorosi (AndreaA) - Saturday, 17 February 2018, 23:16 GMT
No. linux-lts 4.14.19-1 works perfectly.
Comment by loqs (loqs) - Monday, 19 February 2018, 15:50 GMT
Would suggest bisecting the kernel between 4.14 and 4.15. If you need help with the bisection please start a forum thread.
Comment by Denis Mayborodin (Dzen_Python) - Monday, 19 February 2018, 16:50 GMT
4.15.1 working fine with intel-ucode. I saw this bug after upgrading to 4.15.2.
Comment by loqs (loqs) - Monday, 19 February 2018, 18:02 GMT
Was it linux 4.15.1-3/4.15.1-4 that worked and 4.15.2-1 that had the bug?
As there were three/four version of 4.15.1 all with config changes it will narrow it down a lot if you can find which exact package update that introduces the bug.
If you do not have the versions in your package cache has the packages except 4.15.1-4 not sure if that was ever actually released.
Comment by Andrea Amorosi (AndreaA) - Monday, 19 February 2018, 18:26 GMT
In my case all the following kernels:
do not boot if intel-ucode is used.
The last linux package (excluding -lts ones) that works correctly is linux-4.14.15-1-x86_64.pkg.tar.xz
Comment by Nicola (drakkan) - Tuesday, 20 February 2018, 07:52 GMT
on my thinkpad t540p linux 4.15.3-1 boots fine, while 4.15.3-2 often hangs on boot and sometime boots correctly
Comment by loqs (loqs) - Tuesday, 20 February 2018, 19:07 GMT
@drakkan and if you boot the system using 4.15.3-2 without using using intel-ucode.img as an initrd?
Comment by Andrea Amorosi (AndreaA) - Tuesday, 20 February 2018, 19:52 GMT
I've noted something strange/particular.
If I reboot from a working kernel (lts with intel-ucode or not lts without intel-ucode) to load one of these bugged kernel using intel-ucode, it works correctly only the first time, but then if I reboot (or poweroff) it doesn't work anymore hanging at boot.
Then if I try to load a working kernel, the first time it doesn't load, but after that (forcing a poweroff) it starts working again.
It seems to me (but I don't know if it is possible with these complex pc) as if something dirty is put in Bios or Efi using the 4.15-x and intel-ucode and that two reload of a working kernel are needed to correct that.
Maybe the CPU tries to update the ucode and something goes wrong?
Comment by loqs (loqs) - Tuesday, 20 February 2018, 21:23 GMT
It would be much easier for the kernel developers if you could bisect and find the first bad commit so you can contact the right subsystem team from the start.
Opening a general bug report upstream documenting the issue started between 4.14 and 4.15 I would expect no response or you will be requested to perform a bisection anyway.
I can help with the bisection but it will probably clutter this bug report which is why I suggested opening a forum thread for it.
Dzen_Python also needs to do a separate bisection unless it turns out just a config change in the different 4.15.1 releases triggered the issue on that system.
Comment by Nicola (drakkan) - Wednesday, 21 February 2018, 22:09 GMT
@loqs if I boot my system with 4.15.3-2 without using using intel-ucode.img as an initrd the problem is not solved, so maybe this is another issue related to the patch added in 4.15.3-2

4.15.3-2 during boot shows the warning you can see attached that does not happen in 4.15.3-1
Comment by Nicola (drakkan) - Wednesday, 21 February 2018, 22:25 GMT
my problem is solved blacklist nvidiafb so the correct bug is this one:

sorry for the noise
Comment by Denis Mayborodin (Dzen_Python) - Friday, 23 February 2018, 07:53 GMT
I do bisection - on 4.15.1-4 working fine, 4.15.1-2 working fine, 4.15.2-1 - hangs
Comment by Denis Mayborodin (Dzen_Python) - Friday, 23 February 2018, 07:58 GMT
Problem solved installing 4.15.5-1 from testing w/o FB drivers. This patch from Ubuntu...
Comment by Andrea Amorosi (AndreaA) - Friday, 23 February 2018, 23:13 GMT
I still have the same problem with Linux n752vx 4.15.5-1-ARCH #1 SMP PREEMPT Thu Feb 22 22:15:20 UTC 2018 x86_64 GNU/Linux.
It keeps hanging very early if booted with intel-ucode.
Comment by Andrea Amorosi (AndreaA) - Saturday, 24 February 2018, 11:24 GMT
In order to bisect the kernel I've opened this thread with some questions?
Comment by Andrea Amorosi (AndreaA) - Monday, 26 February 2018, 23:20 GMT
linux-lts has started having the same issue since the upgrading to 4.14.22-1
Comment by Federico Cuello (fedux) - Wednesday, 14 March 2018, 11:37 GMT
There is a new version:

Intel Processor Microcode Package for Linux
20180312 Release
Comment by loqs (loqs) - Wednesday, 14 March 2018, 22:35 GMT
4.16-rc5 has some commits for more robust microcode update handling.
Comment by Andrea Amorosi (AndreaA) - Friday, 16 March 2018, 22:30 GMT
The newer micocode does not solve the issue (which is still present in 4.15.9-1-ARCH #1 SMP PREEMPT Sun Mar 11 17:54:33 UTC 2018 x86_64 GNU/Linux)
Comment by loqs (loqs) - Monday, 19 March 2018, 19:37 GMT
You were unable to complete the bisection between 4.14.21 and 4.14.22 which should have been quicker than the 4.14 to 4.15 bisection?