05 Jan, 2011
1 commit
-
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.afterNo change on 32bit.
Finally we can remove MAX_APCIS that was rather confusing.
Signed-off-by: Yinghai Lu
Cc: H. Peter Anvin
Cc: "Eric W. Biederman"
LKML-Reference:
Signed-off-by: Ingo Molnar
08 Jan, 2009
2 commits
-
Impact: cleanup, solve 80 columns wrap problems
It would be cleaner to rename all the mpf->mpf_X fields to
mpf->X - that alone would give 4 characters per usage site.
(we already know that it's an 'mpf' entity -
no need to duplicate that in the field too)Signed-off-by: Jaswinder Singh Rajput
Signed-off-by: Ingo Molnar -
Impact: cleanup, solve 80 columns wrap problems
intel_mp_floating should be renamed to mpf_intel.
The reason: the 'f' in MPF already means 'floating'
which means MP Floating pointer structure -
no need to repeat that in the type name.Signed-off-by: Jaswinder Singh Rajput
Signed-off-by: Ingo Molnar
05 Jan, 2009
7 commits
-
Impact: cleanup, solve 80 columns wrap problems
It would be cleaner to rename all the mpc->mpc_X fields to
mpc->X - that alone would give 4 characters per usage site.
(we already know that it's an 'mpc' entity -
no need to duplicate that in the field too)Signed-off-by: Jaswinder Singh Rajput
Signed-off-by: Ingo Molnar -
Impact: cleanup, solve 80 columns wrap problems
It would be cleaner to rename all the mpc->oem_X fields to
mpc->X - that alone would give 4 characters per usage site.
(we already know that it's an 'oem' entity -
no need to duplicate that in the field too)Signed-off-by: Jaswinder Singh Rajput
Signed-off-by: Ingo Molnar -
Impact: cleanup, solve 80 columns wrap problems
It would be cleaner to rename all the mpc->mpc_X fields to
mpc->X - that alone would give 4 characters per usage site.
(we already know that it's an 'mpc' entity -
no need to duplicate that in the field too)Signed-off-by: Jaswinder Singh Rajput
Signed-off-by: Ingo Molnar -
Impact: cleanup, solve 80 columns wrap problems
It would be cleaner to rename all the mpc->mpc_X fields to
mpc->X - that alone would give 4 characters per usage site.
(we already know that it's an 'mpc' entity -
no need to duplicate that in the field too)Signed-off-by: Jaswinder Singh Rajput
Signed-off-by: Ingo Molnar -
Impact: cleanup, solve 80 columns wrap problems
It would be cleaner to rename all the mpc->mpc_X fields to
mpc->X - that alone would give 4 characters per usage site.
(we already know that it's an 'mpc' entity -
no need to duplicate that in the field too)Signed-off-by: Jaswinder Singh Rajput
Signed-off-by: Ingo Molnar -
Impact: cleanup, solve 80 columns wrap problems
It would be cleaner to rename all the mpc->mpc_X fields to
mpc->X - that alone would give 4 characters per usage site.
(we already know that it's an 'mpc' entity -
no need to duplicate that in the field too)Signed-off-by: Jaswinder Singh Rajput
Signed-off-by: Ingo Molnar -
Impact: cleanup, solve 80 columns wrap problems
It would be cleaner to rename all the mpc->mpc_X fields to
mpc->X - that alone would give 4 characters per usage site.
(we already know that it's an 'mpc' entity -
no need to duplicate that in the field too)Signed-off-by: Jaswinder Singh Rajput
Signed-off-by: Ingo Molnar
04 Jan, 2009
7 commits
-
Impact: cleanup, solve 80 columns wrap problems
mpc_config_oemtable should be renamed to mpc_oemtable.
The reason: the 'c' in MPC already means 'config' -
no need to repeat that in the type name.Signed-off-by: Jaswinder Singh Rajput
Signed-off-by: Ingo Molnar -
Impact: cleanup, solve 80 columns wrap problems
mpc_config_lintsrc should be renamed to mpc_lintsrc.
The reason: the 'c' in MPC already means 'config' -
no need to repeat that in the type name.Signed-off-by: Jaswinder Singh Rajput
Signed-off-by: Ingo Molnar -
Impact: cleanup, solve 80 columns wrap problems
mpc_config_intsrc should be renamed to mpc_intsrc.
The reason: the 'c' in MPC already means 'config' -
no need to repeat that in the type name.Signed-off-by: Jaswinder Singh Rajput
Signed-off-by: Ingo Molnar -
Impact: cleanup, solve 80 columns wrap problems
mpc_config_ioapic should be renamed to mpc_ioapic.
The reason: the 'c' in MPC already means 'config' -
no need to repeat that in the type name.Signed-off-by: Jaswinder Singh Rajput
Signed-off-by: Ingo Molnar -
Impact: cleanup, solve 80 columns wrap problems
mpc_config_processor should be renamed to mpc_cpu.
The reason: the 'c' in MPC already means 'config' -
no need to repeat that in the type name.Plus 'processor' is a lot longer than 'cpu' - so we try to use 'cpu' in all
type names, as much as possible.Signed-off-by: Jaswinder Singh Rajput
Signed-off-by: Ingo Molnar -
Impact: cleanup, solve 80 columns wrap problems
mpc_config_bus should be renamed to mpc_bus.
The reason: the 'c' in MPC already means 'config' -
no need to repeat that in the type name.Signed-off-by: Jaswinder Singh Rajput
Signed-off-by: Ingo Molnar -
Impact: cleanup, solve 80 columns wrap problems
mp_config_table should be renamed to mpc_table.
The reason: the 'c' in MPC already means 'config' -
no need to repeat that in the type name.Signed-off-by: Jaswinder Singh Rajput
Signed-off-by: Ingo Molnar
23 Oct, 2008
2 commits
-
Change header guards named "ASM_X86__*" to "_ASM_X86_*" since:
a. the double underscore is ugly and pointless.
b. no leading underscore violates namespace constraints.Signed-off-by: H. Peter Anvin
-
Signed-off-by: Al Viro
Signed-off-by: H. Peter Anvin