[arch-dev-public] Changes to microcode updates
Intel released a new microcode update that disables an instruction on Haswell CPUs. However, Linux doesn't handle this very well and in combination with our glibc version, this essentially crashes your system. The solution is to use the "new" early microcode update mechanism that was introduced almost two years ago ([1]). This means we need to build microcode support into the kernel. For Intel, the new intel-ucode package provides the file /boot/intel-ucode.img which you can load as the first initrd image. Intel users can follow the instructions at [2]. This is the result on one of my Haswell machines: $ journalctl -b -o short-monotonic | grep updated\ early [ 0.000000] lije kernel: CPU0 microcode updated early to revision 0x1c, date = 2014-07-03 [ 0.091952] lije kernel: CPU1 microcode updated early to revision 0x1c, date = 2014-07-03 [ 0.112570] lije kernel: CPU2 microcode updated early to revision 0x1c, date = 2014-07-03 [ 0.133215] lije kernel: CPU3 microcode updated early to revision 0x1c, date = 2014-07-03 For AMD, a similar mechanism is available, but since I don't own an AMD CPU, I cannot implement this. This causes problems, since the microcode update is no longer triggered automatically on boot (since microcode is no longer a module). If you want to update the AMD ucode, you probably need to run echo > /sys/devices/system/cpu/microcode/reload on boot. I hope someone with an AMD CPU will look into this. I am releasing the following package version to testing right now with these changes: * linux 3.17-2 * linux-lts 3.14.21-2 * intel-ucode 20140913-1 [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Document... [2] https://wiki.archlinux.org/index.php/Microcode#Enabling_Intel_Microcode_Upda...
On 12/10/14 15:28, Thomas Bächler wrote:
For AMD, a similar mechanism is available, but since I don't own an AMD CPU, I cannot implement this. This causes problems, since the microcode update is no longer triggered automatically on boot (since microcode is no longer a module). If you want to update the AMD ucode, you probably need to run echo > /sys/devices/system/cpu/microcode/reload on boot. I hope someone with an AMD CPU will look into this.
I generated amd-ucode.img with the following commands: $ mkdir -p kernel/x86/microcode $ cat /usr/lib/firmware/amd-ucode/microcode_amd*.bin \ >kernel/x86/microcode/AuthenticAMD.bin $ find kernel | bsdcpio -o -H newc -R 0:0 >amd-ucode.img In syslinux.cfg I specified (w/ separate /boot partition): INITRD ../amd-ucode.img,../initramfs-linux.img While the above works fine on my desktop and microcode is updated early like it's supposed to, my laptop with the exact same configuration just hangs at the message "Booting the kernel."
On 12/10/14 18:13, Evangelos Foutras wrote:
On 12/10/14 15:28, Thomas Bächler wrote:
For AMD, a similar mechanism is available, but since I don't own an AMD CPU, I cannot implement this. This causes problems, since the microcode update is no longer triggered automatically on boot (since microcode is no longer a module). If you want to update the AMD ucode, you probably need to run echo > /sys/devices/system/cpu/microcode/reload on boot. I hope someone with an AMD CPU will look into this.
I generated amd-ucode.img with the following commands:
$ mkdir -p kernel/x86/microcode $ cat /usr/lib/firmware/amd-ucode/microcode_amd*.bin \ >kernel/x86/microcode/AuthenticAMD.bin $ find kernel | bsdcpio -o -H newc -R 0:0 >amd-ucode.img
In syslinux.cfg I specified (w/ separate /boot partition):
INITRD ../amd-ucode.img,../initramfs-linux.img
While the above works fine on my desktop and microcode is updated early like it's supposed to, my laptop with the exact same configuration just hangs at the message "Booting the kernel."
I did some further testing on my laptop regarding early microcode loading and it works fine when the kernel is built with either CONFIG_PREEMPT_NONE=y or CONFIG_PREEMPT_VOLUNTARY=y. Our default kernel uses CONFIG_PREEMPT=y, which apparently displeases my laptop greatly... I'm not sure how we should proceed.
participants (2)
-
Evangelos Foutras
-
Thomas Bächler