[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160609154737.GA23149@khazad-dum.debian.net>
Date: Thu, 9 Jun 2016 12:47:37 -0300
From: Henrique de Moraes Holschuh <hmh@....eng.br>
To: "Elliott, Robert (Persistent Memory)" <elliott@....com>
Cc: Andi Kleen <andi@...stfloor.org>,
"x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH] x86/microcode/intel: Quieten down microcode updates on
large systems
On Thu, 09 Jun 2016, Elliott, Robert (Persistent Memory) wrote:
> > + if (val[1] != prev_rev) {
> > + pr_info("CPU updated to revision 0x%x, date = %04x-%02x-
> > %02x\n",
>
> "CPU(s)" would help convey that the messages now apply to one or
> more CPUs.
Agreed, especially because they *already* apply to more than one "cpu"
(because cpu for the kernel is a hardware thread for the hardware, and
updating the microcode for a core usually updates all threads hosted by
that core, thus "several cpus").
And yes, Debian got one or two bugs about people getting confused
because some "cpus" were never "listed" as being updated...
Obviously, it is fine if a simple follow-up patch fixes this message to
say "CPU(s)", or, if we really want to go for minimum chance of
confusion: "One or more CPUs updated to...", as that will help a lot in
mixed-stepping configurations, where you will get a few such messages,
and just saying "CPU(s)" might cause people to get the wrong idea that
the same set of CPUs have been updated several times.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Powered by blists - more mailing lists