linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Borislav Petkov <bp@alien8.de>,
	toshi.kani@hp.com, prarit@redhat.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, linux-acpi@vger.kernel.org
Subject: Re: v3.9 - CPU hotplug and microcode earlier loading hits a mutex deadlock (x86_cpu_hotplug_driver_mutex)
Date: Thu, 09 May 2013 02:23:52 +0200	[thread overview]
Message-ID: <518AEC98.4070507@intel.com> (raw)
In-Reply-To: <20130508163249.GB369@phenom.dumpdata.com>

On 5/8/2013 6:32 PM, 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 wrote:
>>
>> [ … snip some funky BIOS code ]
>>
>>> [here it shifts and continues on testing each CPU bit]
>>>
>>>> Questions over questions...?
>>> I probably went overboard with my answers :-)
>> Konrad, you're killing me! :-) You actually went and looked at the
>> BIOS disassembly voluntarily. You must be insane, I think you should
>> immediately go to the doctor now for a thorough checkup. :-)
>>
>> I think I know who I can sling BIOS issues now to.
> Great .. :-)
>>>> Looks like save_mc_for_early would need another, local mutex to fix that.
>>> Let me try that. Thanks for the suggestion.
>> Ok, seriously now: yeah, this was just an idea, it should at least get
>> the nesting out of the way.
>>
>> About the BIOS deal: you're probably staring at some BIOS out there
>> but is this the way that it is actually going to be implemented on
>> the physical hotplug BIOS? I mean, I've only heard rumors about IVB
>> supporting physical hotplug but do you even have access to such BIOS to
>> verify?
> 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 patch.
>
> Besides that I think this can also appear on VMWare if one is doing
> 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)
>
> Rafael, do you know of any specific Intel hardware that has this implemented?

No, I don't have this information.

By the way, here's a general request.

Please CC any messages having the word "ACPI" anywhere in the body or 
subject to linux-acpi@vger.kernel.org.  I'm really tired of chasing 
ACPI-related threads on the LKML just because people don't care about 
CCing relevant lists and I'm going to NAK all patches touching ACPI in 
any way if they haven't been CCed to the ACPI list.  Seriously.

This particular item may or may not conflict with some ongoing work 
taking place in there (and patches present in my tree).

And you've already had problems with ACPI-related code conflicts, so 
that's not like it's never happened.

Thanks,
Rafael

---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
z siedziba w Gdansku
ul. Slowackiego 173
80-298 Gdansk

Sad Rejonowy Gdansk Polnoc w Gdansku, 
VII Wydzial Gospodarczy Krajowego Rejestru Sadowego, 
numer KRS 101882

NIP 957-07-52-316
Kapital zakladowy 200.000 zl

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

           reply	other threads:[~2013-05-09  0:23 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20130508163249.GB369@phenom.dumpdata.com>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=518AEC98.4070507@intel.com \
    --to=rafael.j.wysocki@intel.com \
    --cc=bp@alien8.de \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=prarit@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=toshi.kani@hp.com \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).