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

[Paul Gideon Dann]

On 27 October 2014 09:55, Christian Hesse <list at eworm.de> wrote:

> Damjan Georgievski <gdamjan at gmail.com> on Thu, 2014/10/23 19:40:
> > On 12 October 2014 14:28, Thomas Bächler <thomas at 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 at 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