summaryrefslogtreecommitdiff
path: root/arch/m68k/lib
diff options
context:
space:
mode:
authorHugh Dickins <hugh@veritas.com>2008-04-30 16:17:46 +0100
committerIngo Molnar <mingo@elte.hu>2008-04-30 23:15:35 +0200
commit5f464707c8c18fccd3c6278ad46ac94b5cf15a98 (patch)
tree6f7c9031a7d5ff01baf9686118e1af7a44f1e894 /arch/m68k/lib
parent5de8f68b43229cce3d457ca9ac6dab8372a35f18 (diff)
x86: fix HT cpu booting on 32-bit
Since recent smpboot 32/64-bit merge, my dual Xeon with HT has been booting only 2 of its 4 cpus (when running an i386 kernel; but x86_64 is okay). J.A. Magallón reports the same. native_cpu_up: bad cpu 2 native_cpu_up: bad cpu 3 The mach-default cpu_present_to_apicid() was just returning cpu number (2, 3) instead of apicid (6, 7): looks like we now need the x86_64 code even for the i386 case. Comparing with other versions of cpu_present_to_apicid(), it seems a good idea to include an NR_CPUS test too, since cpu_present() doesn't include that; but that wasn't a problem here, and may no problem at all. Prior to that smpboot merge, my Xeon booted the two HT siblings on one physical first, then the two siblings on the other physical after - when i386, but alternated them when x86_64. Since the merge, the x86_64 sequence is unchanged, but the i386 sequence is now like x86_64. I prefer this consistency, and I prefer the new sequence: booting with maxcpus=2 then uses the independent physicals without HT sharing. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Diffstat (limited to 'arch/m68k/lib')
0 files changed, 0 insertions, 0 deletions