From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753928Ab1JJUfZ (ORCPT ); Mon, 10 Oct 2011 16:35:25 -0400 Received: from s15228384.onlinehome-server.info ([87.106.30.177]:55918 "EHLO mail.x86-64.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752456Ab1JJUfX (ORCPT ); Mon, 10 Oct 2011 16:35:23 -0400 Date: Mon, 10 Oct 2011 22:35:13 +0200 From: Borislav Petkov To: "Srivatsa S. Bhat" Cc: "tj@kernel.org" , Alan Stern , "rjw@sisk.pl" , "pavel@ucw.cz" , "len.brown@intel.com" , "mingo@elte.hu" , "a.p.zijlstra@chello.nl" , "akpm@linux-foundation.org" , "suresh.b.siddha@intel.com" , "lucas.demarchi@profusion.mobi" , "rusty@rustcorp.com.au" , "rdunlap@xenotime.net" , "vatsa@linux.vnet.ibm.com" , "ashok.raj@intel.com" , "tigran@aivazian.fsnet.co.uk" , "tglx@linutronix.de" , "hpa@zytor.com" , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-doc@vger.kernel.org" Subject: Re: [PATCH v2 0/3] Freezer, CPU hotplug, x86 Microcode: Fix task freezing failures Message-ID: <20111010203513.GB30798@aftab> References: <4E931018.8030904@linux.vnet.ibm.com> <20111010165343.GA29261@aftab> <4E932BBA.9090501@linux.vnet.ibm.com> <20111010175336.GA29415@aftab> <20111010180848.GI8100@google.com> <20111010183442.GC29415@aftab> <20111010185307.GK8100@google.com> <4E9340C2.4090901@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E9340C2.4090901@linux.vnet.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 10, 2011 at 03:00:18PM -0400, Srivatsa S. Bhat wrote: > > Hmm... is it possible to tell whether the core coming online is the > > same one as the last time? If that's possible, the problem becomes > > pretty simple and we can simply tell people who are mixing > > suspend/hibernate with physical hotplug that they're crazy. > > > > I think that is pretty easy, atleast from a microcode revision standpoint: > the collect_cpu_info() function (defined in arch/x86/kernel/microcode_core.c > and arch/x86/kernel/microcode_intel.c or ..._amd.c) can be used for that > purpose. Am I right Boris? Correct, on AMD the PATCH_LEVEL MSR (0x8b) contains the ... doh, current patch level of the core, i.e. the applied ucode version. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551