From: Borislav Petkov <bp@alien8.de>
To: Denys Vlasenko <dvlasenk@redhat.com>
Cc: "H. Peter Anvin" <hpa@linux.intel.com>,
Borislav Petkov <bp@suse.de>, Jacob Shin <jacob.shin@amd.com>,
Jeff Layton <jlayton@redhat.com>,
Prarit Bhargava <prarit@redhat.com>,
Mikulas Patocka <mpatocka@redhat.com>,
Fenghua Yu <fenghua.yu@intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] x86: microcode: report if CPU has up-to-date microcode
Date: Mon, 31 Mar 2014 18:23:40 +0200 [thread overview]
Message-ID: <20140331162340.GB16144@pd.tnic> (raw)
In-Reply-To: <1396188574-2067-1-git-send-email-dvlasenk@redhat.com>
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.
--
next prev parent reply other threads:[~2014-03-31 16:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-30 14:09 [PATCH 1/3] x86: microcode: report if CPU has up-to-date microcode Denys Vlasenko
2014-03-30 14:09 ` [PATCH 2/3] x86: microcode: report if no microcode file was found Denys Vlasenko
2014-03-31 16:26 ` Borislav Petkov
2014-03-30 14:09 ` [PATCH 3/3] x86: microcode: remove unused parameter and redundant variable Denys Vlasenko
2014-03-31 16:23 ` Borislav Petkov [this message]
2014-03-31 17:08 ` [PATCH 1/3] x86: microcode: report if CPU has up-to-date microcode Denys Vlasenko
2014-04-13 16:09 ` Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140331162340.GB16144@pd.tnic \
--to=bp@alien8.de \
--cc=bp@suse.de \
--cc=dvlasenk@redhat.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@linux.intel.com \
--cc=jacob.shin@amd.com \
--cc=jlayton@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=prarit@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox