07 Oct, 2006
1 commit
-
CONFIG_X86_GENERIC is not exclusively CONFIG_SMP, as mach-default/ could
be compiled also for UP archs. The patch fixes compilation error in
include/asm/mach-summit/mach_apic.h in case CONFIG_X86_GENERIC && !CONFIG_SMPSigned-off-by: Jiri Kosina
Acked-by: Keith Mannthey
Signed-off-by: Linus Torvalds
01 Oct, 2006
1 commit
-
This is a the first of a series of patch-sets aiming at making kdump more
robust against stack overflows.This patch set does the following:
* Add safe_smp_processor_id function to i386 architecture (this function was
inspired by the x86_64 function of the same name).* Substitute "smp_processor_id" with the stack overflow-safe
"safe_smp_processor_id" in the reboot path to the second kernel.This patch:
On the event of a stack overflow critical data that usually resides at the
bottom of the stack is likely to be stomped and, consequently, its use should
be avoided.In particular, in the i386 and IA64 architectures the macro smp_processor_id
ultimately makes use of the "cpu" member of struct thread_info which resides
at the bottom of the stack. x86_64, on the other hand, is not affected by
this problem because it benefits from the use of the PDA infrastructure.To circumvent this problem I suggest implementing "safe_smp_processor_id()"
(it already exists in x86_64) for i386 and IA64 and use it as a replacement
for smp_processor_id in the reboot path to the dump capture kernel. This is a
possible implementation for i386.Signed-off-by: Fernando Vazquez
Looks-reasonable-to: Andi Kleen
Acked-by: "Eric W. Biederman"
Cc: Vivek Goyal
Cc: James Bottomley
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
30 Sep, 2006
1 commit
-
Convert the i386 summit subarch apicid_to_node to use node information
provided by the SRAT. It was discussed a little on LKML a few weeks ago
and was seen as an acceptable fix. The current way of obtaining the nodeidstatic inline int apicid_to_node(int logical_apicid)
{
return logical_apicid >> 5;
}is just not correct for all summit systems/bios. Assuming the apicid
matches the Linux node number require a leap of faith that the bios mapped
out the apicids a set way. Modern summit HW (IBM x460) does not layout its
bios in the manner for various reasons and is unable to boot i386 numa.The best way to get the correct apicid to node information is from the SRAT
table during boot. It lays out what apicid belongs to what node. I use
this information to create a table for use at run time.Signed-off-by: Keith Mannthey
Cc: Andi Kleen
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
26 Sep, 2006
2 commits
-
This patch enables ACPI based physical CPU hotplug support for x86_64.
Implements acpi_map_lsapic() and acpi_unmap_lsapic() to support physical cpu
hotplug.Signed-off-by: Ashok Raj
Signed-off-by: Andi Kleen
Cc: Andi Kleen
Cc: "Brown, Len"
Signed-off-by: Andrew Morton -
There are some machines around (large xSeries or Unisys ES7000) that
need physical IO-APIC destination mode to access all of their IO
devices. This currently doesn't work in UP kernels as used in
distribution installers.This patch allows to compile even UP kernels as GENERICARCH which
allows to use physical or clustered APIC mode.Signed-off-by: Andi Kleen
26 Apr, 2006
1 commit
-
Signed-off-by: David Woodhouse
11 Nov, 2005
1 commit
-
MSI hardcoded delivery mode to use logical delivery mode. Recently
x86_64 moved to use physical mode addressing to support physflat mode.
With this mode enabled noticed that my eth with MSI werent working.msi_address_init() was hardcoded to use logical mode for i386 and x86_64.
So when we switch to use physical mode, things stopped working.Since anyway we dont use lowest priority delivery with MSI, its always
directed to just a single CPU. Its safe and simpler to use
physical mode always, even when we use logical delivery mode for IPI's
or other ioapic RTE's.Signed-off-by: Ashok Raj
Signed-off-by: Greg Kroah-Hartman
05 Sep, 2005
1 commit
-
for_each_cpu walks through all processors in cpu_possible_map, which is
defined as cpu_callout_map on i386 and isn't initialised until all
processors have been booted. This breaks things which do for_each_cpu
iterations early during boot. So, define cpu_possible_map as a bitmap with
NR_CPUS bits populated. This was triggered by a patch i'm working on which
does alloc_percpu before bringing up secondary processors.From: Alexander Nyberg
i386-boottime-for_each_cpu-broken.patch
i386-boottime-for_each_cpu-broken-fix.patchThe SMP version of __alloc_percpu checks the cpu_possible_map before
allocating memory for a certain cpu. With the above patches the BSP cpuid
is never set in cpu_possible_map which breaks CONFIG_SMP on uniprocessor
machines (as soon as someone tries to dereference something allocated via
__alloc_percpu, which in fact is never allocated since the cpu is not set
in cpu_possible_map).Signed-off-by: Zwane Mwaikambo
Signed-off-by: Alexander Nyberg
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
29 Jul, 2005
1 commit
-
Signed-off-by: Andi Kleen
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
26 Jun, 2005
4 commits
-
I really wish smp_prepare_cpu() would disappear eventually. In the interim
this is ideally a weak function, so we dont end up changing several places
to define this dummy in headers.Today since the dummy declaration is done only in drivers/base/cpu.c but
the function is called in kernel/power/smp.c i get undefined reference in
my cpu hotplug code for x86_64 under development.Signed-off-by: Ashok Raj
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Clean CPU states in order to reuse smp boot code for CPU hotplug.
Signed-off-by: Li Shaohua
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Make SEP init per-cpu, so it is hotplug safe.
Signed-off-by: Li Shaohua
Signed-off-by: Ashok Raj
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
(The i386 CPU hotplug patch provides infrastructure for some work which Pavel
is doing as well as for ACPI S3 (suspend-to-RAM) work which Li Shaohua
is doing)The following provides i386 architecture support for safely unregistering and
registering processors during runtime, updated for the current -mm tree. In
order to avoid dumping cpu hotplug code into kernel/irq/* i dropped the
cpu_online check in do_IRQ() by modifying fixup_irqs(). The difference being
that on cpu offline, fixup_irqs() is called before we clear the cpu from
cpu_online_map and a long delay in order to ensure that we never have any
queued external interrupts on the APICs. There are additional changes to s390
and ppc64 to account for this change.1) Add CONFIG_HOTPLUG_CPU
2) disable local APIC timer on dead cpus.
3) Disable preempt around irq balancing to prevent CPUs going down.
4) Print irq stats for all possible cpus.
5) Debugging check for interrupts on offline cpus.
6) Hacky fixup_irqs() to redirect irqs when cpus go off/online.
7) play_dead() for offline cpus to spin inside.
8) Handle offline cpus set in flush_tlb_others().
9) Grab lock earlier in smp_call_function() to prevent CPUs going down.
10) Implement __cpu_disable() and __cpu_die().
11) Enable local interrupts in cpu_enable() after fixup_irqs()
12) Don't fiddle with NMI on dead cpu, but leave intact on other cpus.
13) Program IRQ affinity whilst cpu is still in cpu_online_map on offline.Signed-off-by: Zwane Mwaikambo
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
22 Jun, 2005
1 commit
-
This patch implements a number of smp_processor_id() cleanup ideas that
Arjan van de Ven and I came up with.The previous __smp_processor_id/_smp_processor_id/smp_processor_id API
spaghetti was hard to follow both on the implementational and on the
usage side.Some of the complexity arose from picking wrong names, some of the
complexity comes from the fact that not all architectures defined
__smp_processor_id.In the new code, there are two externally visible symbols:
- smp_processor_id(): debug variant.
- raw_smp_processor_id(): nondebug variant. Replaces all existing
uses of _smp_processor_id() and __smp_processor_id(). Defined
by every SMP architecture in include/asm-*/smp.h.There is one new internal symbol, dependent on DEBUG_PREEMPT:
- debug_smp_processor_id(): internal debug variant, mapped to
smp_processor_id().Also, i moved debug_smp_processor_id() from lib/kernel_lock.c into a new
lib/smp_processor_id.c file. All related comments got updated and/or
clarified.I have build/boot tested the following 8 .config combinations on x86:
{SMP,UP} x {PREEMPT,!PREEMPT} x {DEBUG_PREEMPT,!DEBUG_PREEMPT}
I have also build/boot tested x64 on UP/PREEMPT/DEBUG_PREEMPT. (Other
architectures are untested, but should work just fine.)Signed-off-by: Ingo Molnar
Signed-off-by: Arjan van de Ven
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Apr, 2005
2 commits
-
Appended patch adds the support for Intel dual-core detection and displaying
the core related information in /proc/cpuinfo.It adds two new fields "core id" and "cpu cores" to x86 /proc/cpuinfo and the
"core id" field for x86_64("cpu cores" field is already present in x86_64).Number of processor cores in a die is detected using cpuid(4) and this is
documented in IA-32 Intel Architecture Software Developer's Manual (vol 2a)
(http://developer.intel.com/design/pentium4/manuals/index_new.htm#sdm_vol2a)This patch also adds cpu_core_map similar to cpu_sibling_map.
Slightly hacked by AK.
Signed-off-by: Suresh Siddha
Signed-off-by: Andi Kleen
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.Let it rip!
