On 1/15/20, Linus Torvalds torvalds@linux-foundation.org wrote:
However, the most likely cause is that you have a borderline dodgy system, and the microcode update then just triggers a pre-existing problem.
For that particular processor model, there appears to be microcode updates for four steppings: 9 10 11 and 12. My model is stepping 9, so it appears to be early commercially sold version of that model. Probably more problems on it than on later steppings.
But it might be worth it if the intel people could check up with their microcode people on this anyway - if there is _one_ report of "my system locks up with newer ucode", that's one thing. But if Jari isn't alone...
I'm not alone with latest Intel microcode problems. Debian for example reverted microcode to older microcode version on some Intel processor models because of hangs on warm reboots. Those reverts were not for same processor model as my processor, but they do indicate "not everything OK" situation with latest Intel microcodes.
https://lists.debian.org/debian-security-announce/2019/msg00237.html
My laptop computer was made by Dell, and Dell has been really good at providing new BIOS updates (that don't require Microsoft OS to update). More than once they have provided new BIOS to fix some security flaw that was still embargoed. The information about that security flaw then became publically known later after embargo ended.
Now that I have learned about the instability of latest two microcode updates for my laptop's processor, it isn't difficult to connect the dots why Dell is still shipping 3rd latest microcode in their latest BIOS update for that laptop computer.