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  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]
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/

Powered by blists - more mailing lists