FS#42332 - [mkinitcpio] [linux] Late firmware loading causes freezes when instructions are being disabled
Attached to Project:
Arch Linux
Opened by Steven Honeyman (stevenhoneyman) - Saturday, 11 October 2014, 12:26 GMT
Last edited by Thomas Bächler (brain0) - Sunday, 26 October 2014, 11:17 GMT
Opened by Steven Honeyman (stevenhoneyman) - Saturday, 11 October 2014, 12:26 GMT
Last edited by Thomas Bächler (brain0) - Sunday, 26 October 2014, 11:17 GMT
|
Details
Description:
Intel found problems with TSX instructions on their Haswell and above processors, so with the recent microcode update - they just disabled them. Arch's current intel-ucode package provides microcode updates through /usr/lib/firmware/intel-ucode/* and the kernel firmware loader. This is a big problem for anyone that decides to update to the latest microcode(1) with an affected processor - as soon as a reload is done, every process that uses libpthread segfaults. On reboot, systemd has already started when the microcode is updated; so startup just... stops. LKML discussion: https://lkml.org/lkml/2014/9/18/218 Current workarounds/fixes include: * Remove /usr/lib/firmware/intel-ucode and force early load of microcode through a cpio pre-pended to initramfs * Find a way to revert the changes made in glibc commit 1cdbe579482c ("Add the low level infrastructure for pthreads lock elision with TSX") -devel@lists.fedoraproject.org/msg81403.html"> https://www.mail-archive.com/devel@lists.fedoraproject.org/msg81403.html * Hardware blacklist in glibc for HLE support on the affected CPUs (1) packages in Arch repo have been flagged as OOD for some time, latest is directly from Intel, dated 2014-09-15 - http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=24290 |
This task depends upon
More info:
http://www.anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-in-haswell-haswelleep-broadwelly
http://debian.2.n7.nabble.com/Bug-762195-libc6-libpthread-hardware-assisted-lock-elision-hazardous-on-x86-td3364226.html
Adding Thomas as an FYI so that he does not update intel-ucode until I have glibc fixed.
There is no indication whatsoever where to get "microcode.bin" from - intel offers a microcode.dat file which we currently split into cpu-specific firmware files. Anyway, this is a kernel bug, not a glibc one.
To make a microcode.bin that works for all Intel cpus, then:
cat /lib/firmware/intel-ucode/* >microcode.bin
(and then follow the cpio instructions from the kernel docs)