All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Travis <travis@sgi.com>
To: Dmitry Adamushko <dmitry.adamushko@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	Tigran Aivazian <tigran@aivazian.fsnet.co.uk>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jack Steiner <steiner@sgi.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, Andreas Mohr <andi@lisas.de>,
	Hugh Dickins <hugh@veritas.com>,
	Hannes Eder <hannes@hanneseder.net>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/8] SGI x86_64 UV: Limit the number of microcode messages
Date: Tue, 27 Oct 2009 08:21:20 -0700	[thread overview]
Message-ID: <4AE70FF0.10409@sgi.com> (raw)
In-Reply-To: <b647ffbd0910261311n4ac4471el7a32ac41104cf93b@mail.gmail.com>

[Another approach is shown below.]

Dmitry Adamushko wrote:
> 2009/10/26 Mike Travis <travis@sgi.com>:
>>
>> Ingo Molnar wrote:
>>> * Dmitry Adamushko <dmitry.adamushko@gmail.com> wrote:
>>>
>>>> 2009/10/24 Tigran Aivazian <tigran@aivazian.fsnet.co.uk>:
>>>>> On Sat, 24 Oct 2009, Dmitry Adamushko wrote:
>>>>>>> -       printk(KERN_INFO "microcode: CPU%d sig=0x%x, pf=0x%x,
>>>>>>> revision=0x%x\n",
>>>>>>> +       if (cpu_num < 4 || !limit_console_output(false))
>>>>>>> +               printk(KERN_INFO
>>>>>>> +                       "microcode: CPU%d sig=0x%x, pf=0x%x,
>>>>>>> revision=0x%x\n",
>>>>>>>                       cpu_num, csig->sig, csig->pf, csig->rev);
>>>>>>>
>>>>>> Hmm, I guess we wouldn't lose a lot by simply removing those messages
>>>>>> completely. Per-cpu pf/revision is available via /sys anyway.
>>>>> The reason for printing them is that the pf (possibly others?) can
>>>>> change by the update and so the log has this info handy.
>>>> We might store the old sig/pf/revision set as well, export them via
>>>> /sys or/and print them at update-to-new-microcode time.
>>>>
>>>> If it's really so useful to have this info in the log and, at the same
>>>> time, to avoid the flood of messages (which, I guess for the majority
>>>> of systems, are the same) at startup time, we might delay the printout
>>>> until the end of microcode_init(). Then do something like this:
>>>>
>>>> microcode cpu0: up to date version sig, pf, rev          // let's say,
>>>> it was updated by BIOS
>>>> microcode cpus [1 ... 16] : update from sig, pf, rev to sig, pf2, rev2.
>>>>
>>>> Anyway, my humble opinion, is that (at the very least) the current
>>>> patch should be accompanied by a similar version for amd.
>>> yeah. Since we load new microcode on all cpus it's enough to print it for
>>> the boot CPU or so.
>>>
>>> Having the precise microcode version printed (or exposed somewhere in
>>> /sys) is useful - sometimes when there's a weird crash in some prototype CPU
>>> one of the first questions from hw vendors is 'which precise microcode
>>> version was that?'.
>>>
>>>        Ingo
>> I would agree especially in the case where not all the cpus are exactly
>> the same.  But so far, I've only seen variations of the speed of the cpus
>> not it's generic type, in an SSI.  So the version of the microcode was
>> identical in all cases.
> 
> I guess that (at least) a bootup cpu can be updated by BIOS so that it
> may appear to be different.
> Perhaps, cases where some 'broken' cpus have been replaced for others
> with a different "revision" (but still compatible otherwise) might be
> rare but possible (say, big machines with hot-pluggable cpus) ?
> 
> btw., I was thinking of having something like this:
> 
> microcode: cpus [K...L]  platform-specific-format (e.g. for Intel :
> sig, pf, rev)
> microcode: updating...
> microcode: cpus [K...L]  platform-specific-format (e.g. for Intel :
> sig, pf, rev)
> 
> or even just,
> 
> microcode: cpus [ K...L] updated from platform-specific-format-1 to
> platform-specific-format-2
> 
> 
>> Thanks,
>> Mike
>>
> 
> 
> -- Dmitry

Here's another approach...

I wasn't sure how to trigger the printing of the summary, so I winged it.
Looking closer it would appear that perhaps adding a new "summarize"
function to the microcode_ops struct could trigger it?  Note this version
builds but I haven't yet tested it on a live system.

Thanks,
Mike

SGI x86_64 UV: Limit the number of microcode messages

Limit number of microcode messages of the form:

[   50.887135] microcode: CPU0 sig=0x206e5, pf=0x4, revision=0xffff001

Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Dmitry Adamushko <dmitry.adamushko@gmail.com>
Cc: Andreas Mohr <andi@lisas.de>
Cc: Hannes Eder <hannes@hanneseder.net>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Mike Travis <travis@sgi.com>
---
 arch/x86/kernel/microcode_intel.c |   73 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 72 insertions(+), 1 deletion(-)

--- linux.orig/arch/x86/kernel/microcode_intel.c
+++ linux/arch/x86/kernel/microcode_intel.c
@@ -137,6 +137,52 @@
 
 #define exttable_size(et) ((et)->count * EXT_SIGNATURE_SIZE + EXT_HEADER_SIZE)
 
+static struct cpu_signature *cpusigs;
+static cpumask_var_t cpusigslist;
+static int cpusigs_error;
+
+static void summarize_cpu_info(void)
+{
+	char buf[128];
+	int cpu;
+	cpumask_var_t cpulist;
+
+	if (cpusigs_error || !alloc_cpumask_var(&cpulist, GFP_KERNEL)) {
+		printk(KERN_INFO "Can't print microcode summary\n");
+		return;
+	}
+
+	while ((cpu = cpumask_first(cpusigslist)) < nr_cpu_ids) {
+		struct cpu_signature *csig = &cpusigs[cpu];
+		int ncpu = cpu;
+
+		cpumask_clear(cpulist);
+		cpumask_set_cpu(cpu, cpulist);
+
+		/* gather all cpu info with same data */
+		while ((ncpu = cpumask_next(ncpu, cpusigslist)) < nr_cpu_ids)
+			if (csig->sig == cpusigs[ncpu].sig &&
+			    csig->pf  == cpusigs[ncpu].pf &&
+			    csig->rev == cpusigs[ncpu].rev)
+				cpumask_set_cpu(ncpu, cpulist);
+
+		cpulist_scnprintf(buf, sizeof(buf), cpulist);
+
+		printk(KERN_INFO
+			"microcode: CPU%s: sig=0x%x, pf=0x%x, revision=0x%x\n",
+			buf, csig->sig, csig->pf, csig->rev);
+
+		/* clear bits we just processed */
+		cpumask_xor(cpusigslist, cpusigslist, cpulist);
+	}
+
+	/* cleanup */
+	free_cpumask_var(cpulist);
+	free_cpumask_var(cpusigslist);
+	vfree(cpusigs);
+	cpusigs_error = 0;
+}
+
 static int collect_cpu_info(int cpu_num, struct cpu_signature *csig)
 {
 	struct cpuinfo_x86 *c = &cpu_data(cpu_num);
@@ -165,9 +211,34 @@
 	/* get the current revision from MSR 0x8B */
 	rdmsr(MSR_IA32_UCODE_REV, val[0], csig->rev);
 
-	printk(KERN_INFO "microcode: CPU%d sig=0x%x, pf=0x%x, revision=0x%x\n",
+	if (!cpusigs && !cpusigs_error) {
+		if (!alloc_cpumask_var(&cpusigslist, GFP_KERNEL))
+			cpusigs_error = 1;
+		else {
+			cpusigs = vmalloc(sizeof(*cpusigs) * nr_cpu_ids);
+			if (!cpusigs) {
+				free_cpumask_var(cpusigslist);
+				cpusigs_error = 1;
+			}
+		}
+	}
+
+	if (cpusigs_error || cpu_num == 0)
+		printk(KERN_INFO
+			"microcode: CPU%d sig=0x%x, pf=0x%x, revision=0x%x\n",
 			cpu_num, csig->sig, csig->pf, csig->rev);
 
+	else if (!cpusigs_error) {
+		cpusigs[cpu_num].sig = csig->sig;
+		cpusigs[cpu_num].pf = csig->pf;
+		cpusigs[cpu_num].rev = csig->rev;
+		cpumask_set_cpu(cpu_num, cpusigslist);
+
+		/* (XXX Need better method for when to print summary) */
+		if (cpu_num == (num_present_cpus() - 1))
+			summarize_cpu_info();
+	}
+
 	return 0;
 }
 

  reply	other threads:[~2009-10-27 15:21 UTC|newest]

Thread overview: 109+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20091023233743.439628000@alcatraz.americas.sgi.com>
2009-10-23 23:37 ` [PATCH 1/8] SGI x86_64 UV: Add limit console output function Mike Travis
2009-10-24  1:09   ` Frederic Weisbecker
2009-10-26 17:55     ` Mike Travis
2009-11-02 14:15       ` Frederic Weisbecker
2009-10-26  7:02   ` Andi Kleen
2009-10-26 16:10     ` Steven Rostedt
2009-10-26 18:05       ` Mike Travis
2009-10-26 18:51         ` Steven Rostedt
2009-10-26 18:03     ` Mike Travis
2009-10-26 21:55       ` Andi Kleen
2009-10-26 22:07         ` Mike Travis
2009-10-30 19:25         ` [PATCH] x86_64: Limit the number of processor bootup messages Mike Travis
2009-10-30 19:54           ` David Rientjes
2009-10-30 20:39             ` Mike Travis
2009-10-30 23:30               ` David Rientjes
2009-10-31  0:27                 ` Mike Travis
2009-11-02 11:11           ` Andi Kleen
2009-11-02 19:21             ` Mike Travis
2009-11-02 19:34               ` Ingo Molnar
2009-11-02 20:32                 ` Mike Travis
2009-11-04  0:22                   ` Mike Travis
2009-11-04 10:24                     ` Ingo Molnar
2009-11-04 10:31                   ` Ingo Molnar
2009-11-12 22:22               ` Dave Jones
2009-11-12 22:57                 ` H. Peter Anvin
2009-11-12 23:15                   ` Dave Jones
2009-11-13  8:03                     ` Ingo Molnar
2009-11-13  8:11                       ` H. Peter Anvin
2009-11-13  8:18                     ` [tip:x86/debug] x86: Remove the CPU cache size printk's tip-bot for Dave Jones
2009-11-13 22:38                     ` [PATCH] x86: Remove CPU cache size output for non-Intel too Roland Dreier
2009-11-13 22:52                       ` Dave Jones
2009-11-14  0:54                       ` [tip:x86/debug] " tip-bot for Roland Dreier
2009-11-13 16:10                   ` [PATCH] x86_64: Limit the number of processor bootup messages Mike Travis
2009-11-14  0:53                     ` Ingo Molnar
2009-10-23 23:37 ` [PATCH 2/8] SGI x86_64 UV: " Mike Travis
2009-10-26  7:26   ` Andi Kleen
2009-10-23 23:37 ` [PATCH 3/8] SGI x86_64 UV: Limit the number of number of SRAT messages Mike Travis
2009-10-26  7:04   ` Andi Kleen
2009-10-26 18:08     ` Mike Travis
2009-10-27 15:24     ` Mike Travis
2009-10-27 19:45       ` David Rientjes
2009-10-27 20:00         ` Mike Travis
2009-10-27 20:25           ` [patch] x86: reduce srat verbosity in the kernel log David Rientjes
2009-10-27 20:42             ` Mike Travis
2009-10-27 20:48               ` David Rientjes
2009-10-27 23:02                 ` Mike Travis
2009-10-28  3:29                   ` Andi Kleen
2009-10-28  4:08                     ` David Rientjes
2009-10-28  3:53                 ` Yinghai Lu
2009-10-28  4:08                   ` David Rientjes
2009-10-27 20:55             ` Cyrill Gorcunov
2009-10-27 21:06               ` David Rientjes
2009-10-27 21:10                 ` Cyrill Gorcunov
2009-10-28  3:32             ` Andi Kleen
2009-10-28  4:08               ` David Rientjes
2009-10-28  4:11                 ` Andi Kleen
2009-10-28  4:53                   ` [patch v2] " David Rientjes
2009-10-28  5:19                     ` Andi Kleen
2009-10-28  5:24                       ` David Rientjes
2009-11-10 21:08                     ` David Rientjes
2009-11-10 21:33                       ` Ingo Molnar
2009-11-10 21:42                         ` Yinghai Lu
2009-11-10 21:57                           ` Ingo Molnar
2009-11-10 23:09                         ` Mike Travis
2009-11-12 20:56                         ` David Rientjes
2009-11-12 21:14                           ` Mike Travis
2009-11-12 21:20                             ` David Rientjes
2009-10-28 17:02                   ` [patch] " Mike Travis
2009-10-28 20:52                     ` David Rientjes
2009-10-28 21:03                       ` Mike Travis
2009-10-28 21:06                         ` David Rientjes
2009-10-28 21:35                       ` Mike Travis
2009-10-28 21:46                         ` David Rientjes
2009-10-28 22:36                           ` Mike Travis
2009-10-29  8:21                             ` David Rientjes
2009-10-29 16:34                               ` Mike Travis
2009-10-29 19:06                                 ` David Rientjes
2009-10-27 20:16         ` [PATCH 3/8] SGI x86_64 UV: Limit the number of number of SRAT messages Cyrill Gorcunov
2009-10-27 20:23           ` Mike Travis
2009-10-27 20:33             ` Cyrill Gorcunov
2009-10-23 23:37 ` [PATCH 4/8] SGI x86_64 UV: Limit the number of ACPI messages Mike Travis
2009-10-24  3:29   ` Bjorn Helgaas
2009-10-26 18:15     ` Mike Travis
2009-10-26 22:47     ` Thomas Renninger
2009-10-26 21:25       ` Mike Travis
2009-10-27 15:27     ` Mike Travis
2009-10-27 15:51       ` Bjorn Helgaas
2009-10-23 23:37 ` [PATCH 5/8] SGI x86_64 UV: Limit the number of firmware messages Mike Travis
2009-10-23 23:37 ` [PATCH 6/8] SGI x86_64 UV: Limit the number of microcode messages Mike Travis
2009-10-24 20:09   ` Dmitry Adamushko
2009-10-24 21:09     ` Tigran Aivazian
2009-10-24 22:45       ` Dmitry Adamushko
2009-10-25 16:37         ` Ingo Molnar
2009-10-25 17:11           ` Arjan van de Ven
2009-10-25 17:27             ` Ingo Molnar
2009-10-26 18:33               ` Mike Travis
2009-10-26 18:29             ` Mike Travis
2009-10-26 18:29           ` Mike Travis
2009-10-26 20:11             ` Dmitry Adamushko
2009-10-27 15:21               ` Mike Travis [this message]
2009-10-26 18:25         ` Mike Travis
2009-10-26 19:27           ` Borislav Petkov
2009-10-30 19:40         ` [PATCH] x86_64: " Mike Travis
2009-10-26 18:24       ` [PATCH 6/8] SGI x86_64 UV: " Mike Travis
2009-10-26 18:18     ` Mike Travis
2009-10-26  7:05   ` Andi Kleen
2009-10-26 18:34     ` Mike Travis
2009-10-23 23:37 ` [PATCH 7/8] SGI x86_64 UV: Limit the number of scheduler debug messages Mike Travis
2009-10-23 23:37 ` [PATCH 8/8] SGI x86_64 UV: Limit the number of cpu is down messages Mike Travis

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=4AE70FF0.10409@sgi.com \
    --to=travis@sgi.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@lisas.de \
    --cc=dmitry.adamushko@gmail.com \
    --cc=hannes@hanneseder.net \
    --cc=hpa@zytor.com \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=steiner@sgi.com \
    --cc=tglx@linutronix.de \
    --cc=tigran@aivazian.fsnet.co.uk \
    --cc=x86@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.