On Sun, Mar 30, 2014 at 04:09:32PM +0200, Denys Vlasenko wrote:
> Before this change, successful microcode uploads clearly
> indicate that it was done:
>
> microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x1a
> microcode: CPU1 updated to revision 0x29, date = 2013-06-12
>
> whereas if microcode was not uploaded, it is not clear why:
>
> microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x29
> (nothing more)
>
> So, what was it? No microcode file? No microcode for this sig/pf?
> CPU already has microcode with this (or newer) revision?
>
> In practice, it means that I need to ask people to provide me
> with more information ("do you have microcode package installed?
> which version is it?" etc).
Well, hmm.
First of all, microcode version is in /proc/cpuinfo. Issuing the reason
why microcode wasn't loaded in dmesg and then the dmesg ring buffer
wraps around doesn't make a lot of sense, in my not really too humble
opinion.
So, for debugging cases, you're probably going to have to ask for
/proc/cpuinfo anyway and then check the CPU vendor's site for newer
microcode packages and compare, instead of relying that dmesg still
contains that info.
Besides, experience shows that dmesg messages like those tend to spook
users and we don't want that :-)
--
Regards/Gruss,
Boris.
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
