summaryrefslogtreecommitdiff
path: root/arch/x86/kernel/entry_64.S
diff options
context:
space:
mode:
authorVivek Goyal <vgoyal@redhat.com>2011-07-08 13:19:26 -0400
committerH. Peter Anvin <hpa@linux.intel.com>2011-07-08 15:33:35 -0700
commit14cb6dcf0a023f5977461c94d8d5a163c937979b (patch)
tree5e05e51b0caed5485cf027a37878952e6aba3ab8 /arch/x86/kernel/entry_64.S
parentfe0d42203cb5616eeff68b14576a0f7e2dd56625 (diff)
x86, boot: Wait for boot cpu to show up if nr_cpus limit is about to hit
nr_cpus allows one to specify number of possible cpus in the system. Current assumption seems to be that first cpu to show up is boot cpu and this assumption will be broken in kdump scenario where we can be booting on a non boot cpu with nr_cpus=1. It might happen that first cpu we parse is not the cpu we boot on and later we ignore boot cpu. Though code later seems to recognize this anomaly and forcibly sets boot cpu in physical cpu map with following warning. if (!physid_isset(hard_smp_processor_id(), phys_cpu_present_map)) { printk(KERN_WARNING "weird, boot CPU (#%d) not listed by the BIOS.\n", hard_smp_processor_id()); physid_set(hard_smp_processor_id(), phys_cpu_present_map); } This patch waits for boot cpu to show up and starts ignoring the cpus once we have hit (nr_cpus - 1) number of cpus. So effectively we are reserving one slot out of nr_cpus for boot cpu explicitly. Signed-off-by: Vivek Goyal <vgoyal@redhat.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Link: http://lkml.kernel.org/r/20110708171926.GF2930@redhat.com Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Diffstat (limited to 'arch/x86/kernel/entry_64.S')
0 files changed, 0 insertions, 0 deletions