From: Konrad Rzeszutek Wilk Subject: Re: v3.9 - CPU hotplug and microcode earlier loading hits a mutex deadlock (x86_cpu_hotplug_driver_mutex) Date: Wed, 8 May 2013 14:42:06 -0400 Message-ID: <20130508184206.GD11906@phenom.dumpdata.com> References: <20130506125937.GA14036@phenom.dumpdata.com> <20130507190024.GA4303@phenom.dumpdata.com> <20130508125414.GB30955@pd.tnic> <20130508140342.GA8152@phenom.dumpdata.com> <20130508142949.GC30955@pd.tnic> <20130508163249.GB369@phenom.dumpdata.com> <1368037185.30363.58.camel@misato.fc.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: <1368037185.30363.58.camel@misato.fc.hp.com> Sender: linux-kernel-owner@vger.kernel.org To: Toshi Kani Cc: Borislav Petkov , prarit@redhat.com, rafael.j.wysocki@intel.com, isimatu.yasuaki@jp.fujitsu.com, linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, fenghua.yu@intel.com, xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Wed, May 08, 2013 at 12:19:45PM -0600, Toshi Kani wrote: > On Wed, 2013-05-08 at 12:32 -0400, Konrad Rzeszutek Wilk wrote: > > On Wed, May 08, 2013 at 04:29:49PM +0200, Borislav Petkov wrote: > > > On Wed, May 08, 2013 at 10:03:42AM -0400, Konrad Rzeszutek Wilk w= rote: > > >=20 > > > [ =E2=80=A6 snip some funky BIOS code ] > > >=20 > > > > [here it shifts and continues on testing each CPU bit] > > > >=20 > > > > > Questions over questions...? > > > >=20 > > > > I probably went overboard with my answers :-) > > >=20 > > > Konrad, you're killing me! :-) You actually went and looked at th= e > > > BIOS disassembly voluntarily. You must be insane, I think you sho= uld > > > immediately go to the doctor now for a thorough checkup. :-) > > >=20 > > > I think I know who I can sling BIOS issues now to. > >=20 > > Great .. :-) > > >=20 > > > > > Looks like save_mc_for_early would need another, local mutex = to fix that. > > > >=20 > > > > Let me try that. Thanks for the suggestion. > > >=20 > > > Ok, seriously now: yeah, this was just an idea, it should at leas= t get > > > the nesting out of the way. > > >=20 > > > About the BIOS deal: you're probably staring at some BIOS out the= re > > > but is this the way that it is actually going to be implemented o= n > > > the physical hotplug BIOS? I mean, I've only heard rumors about I= VB > > > supporting physical hotplug but do you even have access to such B= IOS to > > > verify? > >=20 > > Unfortunatly not. I am getting an IvyTown box so hopefully that has= this > > support. But I thought that Fenghua did since he mentioned in the p= atch. > >=20 > > Besides that I think this can also appear on VMWare if one is doing= =20 > > CPU hotplug and on some HP machines - let me CC the relevant people > > extracted from drivers/acpi/processor_driver.c. > > (see https://lkml.org/lkml/2013/5/7/588 for the thread) >=20 > >From the stack trace, it looks like a bug in save_mc_for_early(). T= his > function may not call cpu_hotplug_driver_lock() during CPU online. I > suppose it intends to protect from CPU offline when microcode is upda= ted > outside of the boot/CPU online context. If it indeed supports updati= ng > the microcode without using reboot/cpu hotplug, the lock should be he= ld > when such update request is made. Hey Toshi, The fix for this I have posted, but I am more curious whether you have seen on baremetal this issue? Meaning using CPU ACPI hotplug on v3.9? >=20 > Thanks, > -Toshi >=20