Am 28.10.2014 um 11:50 schrieb Paul Gideon Dann: > On 27 October 2014 09:55, Christian Hesse <list@xxxxxxxx> wrote: > >> Damjan Georgievski <gdamjan@xxxxxxxxx> on Thu, 2014/10/23 19:40: >>> On 12 October 2014 14:28, Thomas Bächler <thomas@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx>, 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.
Attachment:
signature.asc
Description: OpenPGP digital signature
