linux-kernel - Re: [PATCH 6/8] SGI x86_64 UV: Limit the number of microcode messages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4AE5EB80.7050201@sgi.com>
Date:	Mon, 26 Oct 2009 11:33:36 -0700
From:	Mike Travis <travis@....com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Arjan van de Ven <arjan@...radead.org>,
	Dmitry Adamushko <dmitry.adamushko@...il.com>,
	Tigran Aivazian <tigran@...azian.fsnet.co.uk>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jack Steiner <steiner@....com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	Andreas Mohr <andi@...as.de>, Hugh Dickins <hugh@...itas.com>,
	Hannes Eder <hannes@...neseder.net>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/8] SGI x86_64 UV: Limit the number of microcode	messages



Ingo Molnar wrote:
> * Arjan van de Ven <arjan@...radead.org> wrote:
> 
>> On Sun, 25 Oct 2009 17:37:04 +0100
>> Ingo Molnar <mingo@...e.hu> wrote:
>>
>>> 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?'.
>> something like /sys/devices/system/cpu/cpu0/microcode/version ?
>>
>> (yes that is there today ;-)
> 
> yeah, i used that for a bug recently.
> 
> Nevertheless it makes sense to print the boot CPU message too - for bugs 
> that crash before we can read out 
> /sys/devices/system/cpu/cpu0/microcode/version.
> 
> 	Ingo

I added the printout of the first few cpus.  I had thought that maybe
printing the cpu info for each new socket discovered, perhaps reducing
that to each new blade or chassis as the number grew, but again it quickly
became more complex that I thought was necessary...(?)

If you get the first cpu started ok, then using a kernel debugger like
KDB, you can usually get the remaining information.

Thanks,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/