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

[Thomas Bächler]

Am 28.10.2014 um 11:50 schrieb 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?

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20141028/a689982a/attachment.bin>