Re: [arch-general] [arch-dev-public] Changes to microcode updates

older
[arch-general] nouveau and nividia...

Damjan Georgievski

23 Oct 2014 23 Oct '14

5:40 p.m.

On 12 October 2014 14:28, Thomas Bächler 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

Show replies by date

Christian Hesse

27 Oct 27 Oct

9:55 a.m.

New subject: [arch-general] [arch-dev-public] Changes to microcode updates

Damjan Georgievski on Thu, 2014/10/23 19:40:

...

On 12 October 2014 14:28, Thomas Bächler 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);}

Paul Gideon Dann

28 Oct 28 Oct

10:50 a.m.

New subject: [arch-general] [arch-dev-public] Changes to microcode updates

On 27 October 2014 09:55, Christian Hesse wrote:

...

Damjan Georgievski on Thu, 2014/10/23 19:40:

...
On 12 October 2014 14:28, Thomas Bächler 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

Eugenio M. Vigo

11:03 a.m.

New subject: [arch-general] [arch-dev-public] Changes to microcode updates

El 28/10/2014 11:50, "Paul Gideon Dann" 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

...

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

Thomas Bächler

5:13 p.m.

New subject: [arch-general] [arch-dev-public] Changes to microcode updates

Am 28.10.2014 um 11:50 schrieb Paul Gideon Dann:

...

On 27 October 2014 09:55, Christian Hesse wrote:

...
Damjan Georgievski on Thu, 2014/10/23 19:40:

...
On 12 October 2014 14:28, Thomas Bächler 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.

3483

Age (days ago)

3488

Last active (days ago)

List overview

Download

4 comments

5 participants

participants (5)

Christian Hesse
Damjan Georgievski
Eugenio M. Vigo
Paul Gideon Dann
Thomas Bächler