Date:	Wed, 30 Apr 2014 22:13:57 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Baoquan He <bhe@...hat.com>
Cc:	linux-kernel@...r.kernel.org, lenb@...nel.org,
	linux-acpi@...r.kernel.org, jiang.liu@...ux.intel.com,
	vgoyal@...hat.com
Subject: Re: [Patch v2] lapic need be checked if available when initialize acpi processor id

On Wednesday, April 30, 2014 02:03:03 PM Baoquan He wrote:
> Hi Rafael,

Hi,

> Thanks for previous review for v1. Later on I thought acpi_lapic is
> more suitable for checking whether LAPIC in MADT is available, and it can
> hanlde both the UP system running SMP kernel with no LAPIC in MADT and kdump
> kernel after multiple CPUs system crashed on non-1st CPU.
> 
> I tested the 1st case by addding "disableapic nr_cpus=1" into cmdline
> of SMP kenrel, and it works. For 2nd case, it works too, below warning
> message is not printed any more. 
> 
> acpi LNXCPU:0a: BIOS reported wrong ACPI id 0 for the processor
> 
> Do you like this idea?

Well, I don't hate it, but you need to make the code build in all
configurations (including ia64).

Thanks!


> On 04/30/14 at 01:55pm, 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@...hat.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) {
> >  		cpu0_initialized = 1;
> >  		/* Handle UP system running SMP kernel, with no LAPIC in MADT */
> >  		if ((cpu_index == -1) && (num_online_cpus() == 1))
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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