summaryrefslogtreecommitdiff
path: root/COPYING
diff options
context:
space:
mode:
authorMax Krasnyansky <maxk@qualcomm.com>2008-08-11 21:55:31 (GMT)
committerIngo Molnar <mingo@elte.hu>2008-08-14 09:18:08 (GMT)
commit23b49c19f6946cc33392a1fc75dd788dd4a90fb7 (patch)
tree499de0366f5915dbd4b0bca718096f48e2c7bf97 /COPYING
parent31677619650cac2bcc9f50920824323b005e3d8a (diff)
downloadlinux-fsl-qoriq-23b49c19f6946cc33392a1fc75dd788dd4a90fb7.tar.xz
x86: resurrect proper handling of maxcpus= kernel option (v2)
For some reason we had two parsers registered for maxcpus=. One in init/main.c and another in arch/x86/smpboot.c. So I nuked the one in arch/x86. Also 64-bit kernels used to handle maxcpus= as documented in Documentation/cpu-hotplug.txt. CPUs with 'id > maxcpus' are initialized but not booted. 32-bit version for some reason ignored them even though all the infrastructure for booting them later is there. In the current mainline both 64 and 32 bit versions are broken. This patch restores the correct behaviour. I've tested x86_64 version on 4- and 8- way Core2 and 2-way Opteron based machines. Various config combinations SMP, !SMP, CPU_HOTPLUG, !CPU_HOTPLUG. Booted with maxcpus=1 and maxcpus=4, etc. Everything is working as expected. So far we've received two reports from different people confirming that 32-bit version also works fine, both on dual core laptops and 16way server machines. [v2: This version fixes visws breakage pointed out by Ingo.] Signed-off-by: Max Krasnyansky <maxk@qualcomm.com> Cc: lizf@cn.fujitsu.com Cc: jeff.chua.linux@gmail.com Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'COPYING')
0 files changed, 0 insertions, 0 deletions