Re: [GIT PULL, v2] x86/microcode tree changes for v3.19

From: Borislav Petkov
Date: Thu Dec 11 2014 - 04:12:53 EST

On Thu, Dec 11, 2014 at 07:25:08AM +0100, Ingo Molnar wrote:
> > Hmm. There's a conflict with commit 02ecc41abcea ("x86,
> > microcode: Limit the microcode reloading to 64-bit for now"),
> Sorry, should have mentioned that explicitly, but forgot about
> it.
> > but I'm going to assume that the issue is fixed now, and that
> > commit fbae4ba8c4a3 ("x86, microcode: Reload microcode on
> > resume") that causes the conflict also handles the 32-bit case
> > correctly. So my merge is going to just remove the X86_64 test,
> > effectively undoing that first commit, ratehr than keep it
> > around.

Yes, this is the intended outcome.

> > If it turns out that the 64-bit limitation needs to be still in
> > place, holler. We can re-do the ugly 64-bit limit thing if
> > required.
> Hm, so in my own conflict resolution I kept that check, last I
> heard Boris was still seeing weirdnesses (read: crashes) on
> 32-bit and I'm not sure even the full series fixes it all.
> In any case, would be nice to double check this and reinstate the
> limitation explicitly if it's still needed, or apply a fix.
> Boris?

The problem was that while I was testing 32-bit on an IVB laptop, the
machine would triple-fault on resuming from disk. Sometimes, not on each
resume cycle. So I thought this was originally caused by the changes to
the early reloading mechanism.

However, I did a coarse bisection all the way back to 3.10 and the issue
still exists. So it either is this particular laptop or 32-bit suspend
from disk has been always broken.

In any case, the current mainline state of the microcode loader should
be the correct one, I've been testing it on AMD and Intel, both early
and/xor late microcode loader, suspend to disk and to ram and all works

stable@ would need addressing at some point but I'd like to leave it in
mainline a bit to see some more testing and backport it to stable when
there's more confidence all is ok.

Thanks guys.


Sent from a fat crate under my desk. Formatting is fine.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at