ACPI: Do not try to set up acpi processor stuff on cores exceeding maxcpus=
Patch is against latest Linus master branch and is expected to be safe bug fix. You get: ACPI: HARDWARE addr space,NOT supported yet for each ACPI defined CPU which status is active, but exceeds maxcpus= count. As these "not booted" CPUs do not run an idle routine and echo X >/proc/acpi/processor/*/throttling did not work I couldn't find a way to really access not onlined/booted machines. Still this should get fixed and /proc/acpi/processor/X dirs of cores exceeding maxcpus should not show up. I wonder whether this could get cleaned up by truncating possible cpu mask and nr_cpu_ids to setup_max_cpus early some day (and not exporting setup_max_cpus anymore then). But this needs touching of a lot other places... Signed-off-by: Thomas Renninger <trenn@suse.de> CC: travis@sgi.com CC: linux-acpi@vger.kernel.org CC: lenb@kernel.org Signed-off-by: Len Brown <len.brown@intel.com>
This commit is contained in:
parent
3975d16760
commit
75cbfb97a1
2 changed files with 8 additions and 1 deletions
|
@ -581,6 +581,11 @@ static int __cpuinit acpi_processor_add(struct acpi_device *device)
|
||||||
return 0;
|
return 0;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
#ifdef CONFIG_SMP
|
||||||
|
if (pr->id >= setup_max_cpus && pr->id != 0)
|
||||||
|
return 0;
|
||||||
|
#endif
|
||||||
|
|
||||||
BUG_ON((pr->id >= nr_cpu_ids) || (pr->id < 0));
|
BUG_ON((pr->id >= nr_cpu_ids) || (pr->id < 0));
|
||||||
|
|
||||||
/*
|
/*
|
||||||
|
|
|
@ -125,7 +125,9 @@ static char *ramdisk_execute_command;
|
||||||
|
|
||||||
#ifdef CONFIG_SMP
|
#ifdef CONFIG_SMP
|
||||||
/* Setup configured maximum number of CPUs to activate */
|
/* Setup configured maximum number of CPUs to activate */
|
||||||
unsigned int __initdata setup_max_cpus = NR_CPUS;
|
unsigned int setup_max_cpus = NR_CPUS;
|
||||||
|
EXPORT_SYMBOL(setup_max_cpus);
|
||||||
|
|
||||||
|
|
||||||
/*
|
/*
|
||||||
* Setup routine for controlling SMP activation
|
* Setup routine for controlling SMP activation
|
||||||
|
|
Loading…
Reference in a new issue