Re: [arch-general] [arch-dev-public] Changes to microcode updates
On 12 October 2014 14:28, Thomas Bächler <thomas@archlinux.org> wrote:
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.
from that documentation I didn't understand why can't the microcode be part of the standard /boot/initramfs-linux.img in ArchLinux?
[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Document...
-- damjan
Damjan Georgievski <gdamjan@gmail.com> on Thu, 2014/10/23 19:40:
On 12 October 2014 14:28, Thomas Bächler <thomas@archlinux.org> wrote:
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.
Works perfectly here: Just concatenating the ucode and default initramfs into one file, then boot that with grub. Details can be found here: https://bugs.archlinux.org/task/42354#comment129209 May be worth it to change mkinitcpio to combine the two files...
from that documentation I didn't understand why can't the microcode be part of the standard /boot/initramfs-linux.img in ArchLinux?
Just tested, that does not work. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);}
On 27 October 2014 09:55, Christian Hesse <list@eworm.de> wrote:
Damjan Georgievski <gdamjan@gmail.com> on Thu, 2014/10/23 19:40:
On 12 October 2014 14:28, Thomas Bächler <thomas@archlinux.org> wrote:
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.
Question: how do microcode updates interact with waking the machine from sleep? I've added the microcode update as an initrd, and it updated fine when I rebooted. However, having since suspended and woken my machine, the kernel log shows a second load of the microcode: [ 0.000000] CPU0 microcode updated early to revision 0x1c, date = 2014-07-03 [ 0.090603] CPU1 microcode updated early to revision 0x1c, date = 2014-07-03 [ 0.111347] CPU2 microcode updated early to revision 0x1c, date = 2014-07-03 [ 0.132113] CPU3 microcode updated early to revision 0x1c, date = 2014-07-03 [ 0.334871] microcode: CPU0 sig=0x306c3, pf=0x2, revision=0x1c [ 0.334881] microcode: CPU1 sig=0x306c3, pf=0x2, revision=0x1c [ 0.334886] microcode: CPU2 sig=0x306c3, pf=0x2, revision=0x1c [ 0.334892] microcode: CPU3 sig=0x306c3, pf=0x2, revision=0x1c [ 0.334931] microcode: Microcode Update Driver: v2.00 < tigran@aivazian.fsnet.co.uk>, Peter Oruba [ 7802.735878] CPU1 microcode updated early to revision 0x1c, date = 2014-07-03 [ 7802.749970] CPU2 microcode updated early to revision 0x1c, date = 2014-07-03 [ 7802.764074] CPU3 microcode updated early to revision 0x1c, date = 2014-07-03 Note that CPU0 doesn't seem to have been updated. Suspending and resuming again yields a further update to CPUs 1,2,3, but not 0. I'm also getting sporadic failures to launch certain binaries, with an "illegal hardware instruction" error. I'm on kernel 3.17.1-1, which may have something to do with it. I'm aware that 3.17.2 will behave differently with regard to loading microcode. So is this expected behaviour? Any information / ideas / theories? Paul
El 28/10/2014 11:50, "Paul Gideon Dann" <pdgiddie@gmail.com> escribió:
Question: how do microcode updates interact with waking the machine from sleep? I've added the microcode update as an initrd, and it updated fine when I rebooted. However, having since suspended and woken my machine, the kernel log shows a second load of the microcode:
[ 0.000000] CPU0 microcode updated early to revision 0x1c, date = 2014-07-03 [ 0.090603] CPU1 microcode updated early to revision 0x1c, date = 2014-07-03 [ 0.111347] CPU2 microcode updated early to revision 0x1c, date = 2014-07-03 [ 0.132113] CPU3 microcode updated early to revision 0x1c, date = 2014-07-03 [ 0.334871] microcode: CPU0 sig=0x306c3, pf=0x2, revision=0x1c [ 0.334881] microcode: CPU1 sig=0x306c3, pf=0x2, revision=0x1c [ 0.334886] microcode: CPU2 sig=0x306c3, pf=0x2, revision=0x1c [ 0.334892] microcode: CPU3 sig=0x306c3, pf=0x2, revision=0x1c [ 0.334931] microcode: Microcode Update Driver: v2.00 < tigran@aivazian.fsnet.co.uk>, Peter Oruba [ 7802.735878] CPU1 microcode updated early to revision 0x1c, date = 2014-07-03 [ 7802.749970] CPU2 microcode updated early to revision 0x1c, date = 2014-07-03 [ 7802.764074] CPU3 microcode updated early to revision 0x1c, date = 2014-07-03
Note that CPU0 doesn't seem to have been updated. Suspending and resuming again yields a further update to CPUs 1,2,3, but not 0. I'm also getting sporadic failures to launch certain binaries, with an "illegal hardware instruction" error.
I'm on kernel 3.17.1-1, which may have something to do with it. I'm aware that 3.17.2 will behave differently with regard to loading microcode. So
is
this expected behaviour?
Any information / ideas / theories?
Paul
Hi, Not sure if related but I've posted in the forums [1] about the problems I'm having since the 3.17.1-1 update when resuming my system from disk (I preferred to do so rather than spamming hete in order to know whether other users were experiencing the same or not). In a nutshell, I'm experiencing random reboots when resuming from disk. Again, I'm not sure whether this is also due to how ucodes are loaded now, but it looks quite suspicious to me. Cheers, Eugenio [1] https://bbs.archlinux.org/viewtopic.php?id=189014
Am 28.10.2014 um 11:50 schrieb Paul Gideon Dann:
On 27 October 2014 09:55, Christian Hesse <list@eworm.de> wrote:
Damjan Georgievski <gdamjan@gmail.com> on Thu, 2014/10/23 19:40:
On 12 October 2014 14:28, Thomas Bächler <thomas@archlinux.org> wrote:
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.
Question: how do microcode updates interact with waking the machine from sleep? I've added the microcode update as an initrd, and it updated fine when I rebooted. However, having since suspended and woken my machine, the kernel log shows a second load of the microcode:
[ 0.000000] CPU0 microcode updated early to revision 0x1c, date = 2014-07-03 [ 0.090603] CPU1 microcode updated early to revision 0x1c, date = 2014-07-03 [ 0.111347] CPU2 microcode updated early to revision 0x1c, date = 2014-07-03 [ 0.132113] CPU3 microcode updated early to revision 0x1c, date = 2014-07-03 [ 0.334871] microcode: CPU0 sig=0x306c3, pf=0x2, revision=0x1c [ 0.334881] microcode: CPU1 sig=0x306c3, pf=0x2, revision=0x1c [ 0.334886] microcode: CPU2 sig=0x306c3, pf=0x2, revision=0x1c [ 0.334892] microcode: CPU3 sig=0x306c3, pf=0x2, revision=0x1c [ 0.334931] microcode: Microcode Update Driver: v2.00 < tigran@aivazian.fsnet.co.uk>, Peter Oruba [ 7802.735878] CPU1 microcode updated early to revision 0x1c, date = 2014-07-03 [ 7802.749970] CPU2 microcode updated early to revision 0x1c, date = 2014-07-03 [ 7802.764074] CPU3 microcode updated early to revision 0x1c, date = 2014-07-03
Note that CPU0 doesn't seem to have been updated. Suspending and resuming again yields a further update to CPUs 1,2,3, but not 0. I'm also getting sporadic failures to launch certain binaries, with an "illegal hardware instruction" error.
I'm on kernel 3.17.1-1, which may have something to do with it. I'm aware that 3.17.2 will behave differently with regard to loading microcode. So is this expected behaviour?
Any information / ideas / theories?
In theory, the ucode should be updated after resume. I don't know if this is only true for the CPU which get disabled before sleep, or if CPU0 also needs an update.
participants (5)
-
Christian Hesse
-
Damjan Georgievski
-
Eugenio M. Vigo
-
Paul Gideon Dann
-
Thomas Bächler