kernel-fxtec-pro1x/arch/x86/kernel/acpi
Yinghai Lu cb2ded37fd x86: Fix APIC ID sizing bug on larger systems, clean up MAX_APICS confusion
Found one x2apic pre-enabled system, x2apic_mode suddenly get
corrupted after register some cpus, when compiled
CONFIG_NR_CPUS=255 instead of 512.

It turns out that generic_processor_info() ==> phyid_set(apicid,
phys_cpu_present_map) causes the problem.

phys_cpu_present_map is sized by MAX_APICS bits, and pre-enabled
system some cpus have an apic id > 255.

The variable after phys_cpu_present_map may get corrupted
silently:

 ffffffff828e8420 B phys_cpu_present_map
 ffffffff828e8440 B apic_verbosity
 ffffffff828e8444 B local_apic_timer_c2_ok
 ffffffff828e8448 B disable_apic
 ffffffff828e844c B x2apic_mode
 ffffffff828e8450 B x2apic_disabled
 ffffffff828e8454 B num_processors
 ...

Actually phys_cpu_present_map is referenced via apic id, instead
index. We should use MAX_LOCAL_APIC instead MAX_APICS.

For 64-bit it will be 32768 in all cases. BSS will increase by 4k bytes
on 64-bit:

	text		data		bss		dec		filename
	21696943	4193748		12787712	38678403	vmlinux.before
	21696943	4193748		12791808	38682499	vmlinux.after

No change on 32bit.

Finally we can remove MAX_APCIS that was rather confusing.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: H. Peter Anvin <hpa@linux.intel.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
LKML-Reference: <4D23BD9C.3070102@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-01-05 14:09:23 +01:00
..
realmode x86: Use symbolic MSR names 2010-07-21 21:23:40 -07:00
boot.c x86: Fix APIC ID sizing bug on larger systems, clean up MAX_APICS confusion 2011-01-05 14:09:23 +01:00
cstate.c Merge branch 'x86-idle-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip 2010-10-21 13:45:38 -07:00
Makefile ACPI: processor: unify arch_acpi_processor_cleanup_pdc 2009-12-22 03:24:14 -05:00
sleep.c x86-32, mm: Remove duplicated include 2010-10-25 10:05:13 -07:00
sleep.h
wakeup_32.S Rename .text.page_aligned to .text..page_aligned. 2010-03-03 11:26:00 +01:00
wakeup_64.S
wakeup_rm.S