Comment 8 for bug 1370352

On Wed, 17 Sep 2014, Felix Geyer wrote:
> Both "yes" and "early" work fine.

Thank you. That helps immensely!

At least now we have an easy possible workaround: blacklist a few cpuids in
the package postinst from a runtime update, or drop runtime update entirely
and always require a reboot.

> However when I set IUCODE_TOOL_INITRAMFS=no, update the initramfs, reboot
> and then reinstall intel-microcode I get the same trap invalid opcode.
>
> I guess no processes that use libpthread run during early boot when the
> microcode update is applied.

Felix, if it wouldn't be too much trouble, maybe you could attach a copy of
/proc/cpuinfo with microcode 0x1c (the new one), and one with either
microcode 0x16 (no microcode update at all), or with microcode 0x1a (the
previous release of intel-microcode) to this bug report?

It would be necessary to reboot between the microcode changes in that case
and use the early initramfs mode, so that we can be sure the "flags" line in
/proc/cpuinfo will be correct (it is set at boot time, and will not be
updated by a microcode update). You can use the early initramfs update
mode, which is always safer.

It would be also nice to know what instructions are trapping, and get Intel
enginers to look at it. I will leave that for the Canonical Intel team, as
they can contact Intel directly: I don't have that kind of access to Intel
engineers...

For the record, we have these scenarios:

cpuid 0x306c3, platform flags 0x02:
Microcode 0x16 to 0x1c, early mode and initramfs: OK online: FAIL
Microcode 0x16 to 0x1a, early mode and initramfs: OK online: OK
Microcode 0x1a to 0x1c, early mode and initramfs: N/A online: FAIL

FAIL: processor generates spurious invalid opcode traps on libpthread.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh