Re: [Patch v2] lapic need be checked if available when initialize acpi processor id
On Friday, May 02, 2014 04:51:46 PM Baoquan He wrote: > On 04/30/14 at 10:13pm, Rafael J. Wysocki wrote: > > 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). > > > Hi Rafael, > > Sorry about this, I didn't realize acpi_lapic is for x86 only. And ia64 > uses it too. About this bug, it should exist in ia64 too. After checking > code, introducing acpi_lapic into ia64 is a solution, I will try to find > a ia64 machine to test this though it's a little difficult, since people > around didn't test ia64 recently. > > Any suggestion or comment? The plan sounds good, thanks! -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v2] lapic need be checked if available when initialize acpi processor id
On 04/30/14 at 10:13pm, Rafael J. Wysocki wrote: > 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). > Hi Rafael, Sorry about this, I didn't realize acpi_lapic is for x86 only. And ia64 uses it too. About this bug, it should exist in ia64 too. After checking code, introducing acpi_lapic into ia64 is a solution, I will try to find a ia64 machine to test this though it's a little difficult, since people around didn't test ia64 recently. Any suggestion or comment? Thanks Baoquan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v2] lapic need be checked if available when initialize acpi processor id
On 04/30/14 at 10:13pm, Rafael J. Wysocki wrote: 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). Hi Rafael, Sorry about this, I didn't realize acpi_lapic is for x86 only. And ia64 uses it too. About this bug, it should exist in ia64 too. After checking code, introducing acpi_lapic into ia64 is a solution, I will try to find a ia64 machine to test this though it's a little difficult, since people around didn't test ia64 recently. Any suggestion or comment? Thanks Baoquan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v2] lapic need be checked if available when initialize acpi processor id
On Friday, May 02, 2014 04:51:46 PM Baoquan He wrote: On 04/30/14 at 10:13pm, Rafael J. Wysocki wrote: 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). Hi Rafael, Sorry about this, I didn't realize acpi_lapic is for x86 only. And ia64 uses it too. About this bug, it should exist in ia64 too. After checking code, introducing acpi_lapic into ia64 is a solution, I will try to find a ia64 machine to test this though it's a little difficult, since people around didn't test ia64 recently. Any suggestion or comment? The plan sounds good, thanks! -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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
> > ---
> > 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 majord...@vger.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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v2] lapic need be checked if available when initialize acpi processor id
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
> ---
> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v2] lapic need be checked if available when initialize acpi processor id
Hi Rafael,
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?
Thanks
Baoquan
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
> ---
> 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))
> --
> 1.8.5.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v2] lapic need be checked if available when initialize acpi processor id
Hi Rafael,
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?
Thanks
Baoquan
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 b...@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) {
cpu0_initialized = 1;
/* Handle UP system running SMP kernel, with no LAPIC in MADT */
if ((cpu_index == -1) (num_online_cpus() == 1))
--
1.8.5.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v2] lapic need be checked if available when initialize acpi processor id
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 b...@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.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 b...@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) {
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 majord...@vger.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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
