All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Baoquan He <bhe@redhat.com>
Cc: linux-kernel@vger.kernel.org, lenb@kernel.org,
	linux-acpi@vger.kernel.org, jiang.liu@linux.intel.com,
	vgoyal@redhat.com
Subject: Re: [Patch v2] lapic need be checked if available when initialize acpi processor id
Date: Wed, 30 Apr 2014 22:11:34 +0200	[thread overview]
Message-ID: <8303149.p62vWCFBDA@vostro.rjw.lan> (raw)
In-Reply-To: <20140430055503.GD4774@dhcp-16-105.nay.redhat.com>

On Wednesday, April 30, 2014 01:55:03 PM Baoquan He wrote:
> In acpi_processor_get_info(), acpi processor info is initialized including
> id, namely cpu index. Currently, if on UP system running SMP kerenl with
> no LAPIC in MADT, cpu0_initialized is checked if acpi processor id is
> initialized.
> 
> However this check maybe is not correct for kdump kernel. Most of time
> only 1 CPU is supported because of known problems. So in 1st kernel
> multiple CPUs are present, then crash happened in one specific CPU,
> say 2nd CPU. Then it jump into kdump kernel with "nr_cpus=1" specified
> in cmdline. In this situation, since kdump kernel is warm reset, it will
> reuse the ACPI resource passed from crashed kernel directly, namely 1st
> kernel. It means in MADT all LAPIC is enabled while only 1 CPU is
> present in running system. The kdump kernel usually is the same as the
> crashed 1st kernel. So now in kdump kernel, x86_cpu_to_apicid stored the
> apicid and its related cpu id. If only check cpu0_initialized, it will
> assign 0 to the acpi processor id of 1st CPU, it's not correct.
> 
> So in this patch, check acpi_lapic too. If acpi_lapic is 0, then LAPIC in
> MADT is not available, assigne 0 to the handling acpi processor. If
> acpi_lapic is 1, then LAPIC in MADT is available, let's get apic processor
> id from x86_cpu_to_apicid.
> 
> Signed-off-by: Baoquan He <bhe@redhat.com>
> ---
>  drivers/acpi/acpi_processor.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> index c29c2c3..33f934d 100644
> --- a/drivers/acpi/acpi_processor.c
> +++ b/drivers/acpi/acpi_processor.c
> @@ -267,7 +267,7 @@ static int acpi_processor_get_info(struct acpi_device *device)
>  	pr->apic_id = apic_id;
>  
>  	cpu_index = acpi_map_cpuid(pr->apic_id, pr->acpi_id);
> -	if (!cpu0_initialized) {
> +	if (!cpu0_initialized && !acpi_lapic) {

That doesn't compile:

drivers/acpi/acpi_processor.c:271:28: error: 'acpi_lapic' undeclared (first use in this function)

>  		cpu0_initialized = 1;
>  		/* Handle UP system running SMP kernel, with no LAPIC in MADT */
>  		if ((cpu_index == -1) && (num_online_cpus() == 1))
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

      parent reply	other threads:[~2014-04-30 20:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-14 23:55 [PATCH] acpi: try to trust cpu_index from x86_cpu_to_apicid Baoquan He
2014-04-21 20:51 ` Rafael J. Wysocki
2014-04-23 14:40   ` Baoquan He
2014-04-28  2:19   ` Baoquan He
2014-04-30  5:55 ` [Patch v2] lapic need be checked if available when initialize acpi processor id Baoquan He
2014-04-30  6:03   ` Baoquan He
2014-04-30 20:13     ` Rafael J. Wysocki
2014-05-02  8:51       ` Baoquan He
2014-05-02 12:10         ` Rafael J. Wysocki
2014-04-30 20:11   ` Rafael J. Wysocki [this message]

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=8303149.p62vWCFBDA@vostro.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=bhe@redhat.com \
    --cc=jiang.liu@linux.intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vgoyal@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.