public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.
--

  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