Revision tags: v2.6.35, v2.6.35-rc6, v2.6.35-rc5, v2.6.35-rc4, v2.6.35-rc3, v2.6.35-rc2, v2.6.35-rc1, v2.6.34, v2.6.34-rc7, v2.6.34-rc6, v2.6.34-rc5, v2.6.34-rc4, v2.6.34-rc3, v2.6.34-rc2, v2.6.34-rc1, v2.6.33, v2.6.33-rc8 |
|
#
32974ad4 |
| 08-Feb-2010 |
Tony Luck <tony.luck@intel.com> |
[IA64] Remove COMPAT_IA32 support
This has been broken since May 2008 when Al Viro killed altroot support. Since nobody has complained, it would appear that there are no users of this code (A plausi
[IA64] Remove COMPAT_IA32 support
This has been broken since May 2008 when Al Viro killed altroot support. Since nobody has complained, it would appear that there are no users of this code (A plausible theory since the main OSVs that support ia64 prefer to use the IA32-EL software emulation).
Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.33-rc7, v2.6.33-rc6, v2.6.33-rc5, v2.6.33-rc4, v2.6.33-rc3, v2.6.33-rc2, v2.6.33-rc1, v2.6.32, v2.6.32-rc8, v2.6.32-rc7, v2.6.32-rc6 |
|
#
877105cc |
| 29-Oct-2009 |
Tejun Heo <tj@kernel.org> |
percpu: make percpu symbols in ia64 unique
This patch updates percpu related symbols in ia64 such that percpu symbols are unique and don't clash with local symbols. This serves two purposes of decr
percpu: make percpu symbols in ia64 unique
This patch updates percpu related symbols in ia64 such that percpu symbols are unique and don't clash with local symbols. This serves two purposes of decreasing the possibility of global percpu symbol collision and allowing dropping per_cpu__ prefix from percpu symbols.
* arch/ia64/kernel/setup.c: s/cpu_info/ia64_cpu_info/
Partly based on Rusty Russell's "alloc_percpu: rename percpu vars which cause name clashes" patch.
Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Christoph Lameter <cl@linux-foundation.org> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Tony Luck <tony.luck@intel.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: linux-ia64@vger.kernel.org
show more ...
|
Revision tags: v2.6.32-rc5, v2.6.32-rc4, v2.6.32-rc3 |
|
#
52594762 |
| 01-Oct-2009 |
Tejun Heo <tj@kernel.org> |
ia64: convert to dynamic percpu allocator
Unlike other archs, ia64 reserves space for percpu areas during early memory initialization. These areas occupy a contiguous region indexed by cpu number o
ia64: convert to dynamic percpu allocator
Unlike other archs, ia64 reserves space for percpu areas during early memory initialization. These areas occupy a contiguous region indexed by cpu number on contiguous memory model or are grouped by node on discontiguous memory model.
As allocation and initialization are done by the arch code, all that setup_per_cpu_areas() needs to do is communicating the determined layout to the percpu allocator. This patch implements setup_per_cpu_areas() for both contig and discontig memory models and drops HAVE_LEGACY_PER_CPU_AREA.
Please note that for contig model, the allocation itself is modified only to allocate for possible cpus instead of NR_CPUS. As dynamic percpu allocator can handle non-direct mapping, there's no reason to allocate memory for cpus which aren't possible.
Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Tony Luck <tony.luck@intel.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: linux-ia64 <linux-ia64@vger.kernel.org>
show more ...
|
#
12cda817 |
| 01-Oct-2009 |
Tejun Heo <tj@kernel.org> |
ia64: initialize cpu maps early
All information necessary to initialize cpu possible and present maps are available once early_acpi_boot_init() is complete. Reorganize setup_arch() and acpi init fu
ia64: initialize cpu maps early
All information necessary to initialize cpu possible and present maps are available once early_acpi_boot_init() is complete. Reorganize setup_arch() and acpi init functions such that,
* CPU information is printed after LAPIC entries are parsed in early_acpi_boot_init().
* smp_build_cpu_map() is called by setup_arch() instead of acpi functions.
* smp_build_cpu_map() is called once all CPU related information is available before memory is initialized.
This is primarily to allow find_memory() to use cpu maps but is also a general cleanup. Please note that with this change, the somewhat ad-hoc early_cpu_possible_map defined and used for NUMA configurations is probably unnecessary. Something to clean up another day.
Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Tony Luck <tony.luck@intel.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: linux-ia64 <linux-ia64@vger.kernel.org>
show more ...
|
Revision tags: v2.6.32-rc1, v2.6.32-rc2, v2.6.31, v2.6.31-rc9, v2.6.31-rc8, v2.6.31-rc7, v2.6.31-rc6, v2.6.31-rc5, v2.6.31-rc4, v2.6.31-rc3 |
|
#
872fb6dd |
| 13-Jul-2009 |
Fenghua Yu <fenghua.yu@intel.com> |
ia64: Fix setup_per_cpu_areas() compilation error
Fix ia64 build setup_per_cpu_areas() redifinition issue in UP configuration. When compiling ia64 kernel in UP configuration, the following compilat
ia64: Fix setup_per_cpu_areas() compilation error
Fix ia64 build setup_per_cpu_areas() redifinition issue in UP configuration. When compiling ia64 kernel in UP configuration, the following compilation errors are reported:
arch/ia64/kernel/setup.c:860: error: redefinition of 'setup_per_cpu_areas' include/linux/percpu.h:185: error: previous definition of 'setup_per_cpu_areas' was here
The patch fixes the issue in arch/ia64/kernel/setup.c
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: Tejun Heo <tj@kernel.org>
show more ...
|
Revision tags: v2.6.31-rc2, v2.6.31-rc1, v2.6.30, v2.6.30-rc8, v2.6.30-rc7 |
|
#
e088a4ad |
| 22-May-2009 |
Matthew Wilcox <matthew@wil.cx> |
[IA64] Convert ia64 to use int-ll64.h
It is generally agreed that it would be beneficial for u64 to be an unsigned long long on all architectures. ia64 (in common with several other 64-bit architec
[IA64] Convert ia64 to use int-ll64.h
It is generally agreed that it would be beneficial for u64 to be an unsigned long long on all architectures. ia64 (in common with several other 64-bit architectures) currently uses unsigned long. Migrating piecemeal is too painful; this giant patch fixes all compilation warnings and errors that come as a result of switching to use int-ll64.h.
Note that userspace will still see __u64 defined as unsigned long. This is important as it affects C++ name mangling.
[Updated by Tony Luck to change efi.h:efi_freemem_callback_t to use u64 for start/end rather than unsigned long]
Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.30-rc6, v2.6.30-rc5, v2.6.30-rc4, v2.6.30-rc3, v2.6.30-rc2, v2.6.30-rc1, v2.6.29, v2.6.29-rc8 |
|
#
80a03e29 |
| 10-Mar-2009 |
Stoyan Gaydarov <stoyboyker@gmail.com> |
[IA64] BUG to BUG_ON changes
Replace:
if (test) BUG();
with BUG_ON(test);
Signed-off-by: Stoyan Gaydarov <stoyboyker@gmail.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
|
#
03f511dd |
| 04-Mar-2009 |
Isaku Yamahata <yamahata@valinux.co.jp> |
ia64/pv_ops: implement binary patching optimization for native.
implement binary patching optimization for pv_cpu_ops. With this optimization, indirect call for pv_cpu_ops methods can be converted i
ia64/pv_ops: implement binary patching optimization for native.
implement binary patching optimization for pv_cpu_ops. With this optimization, indirect call for pv_cpu_ops methods can be converted into inline execution or direct call.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
#
5dd3c994 |
| 15-Mar-2009 |
Rusty Russell <rusty@rustcorp.com.au> |
cpumask: prepare for iterators to only go to nr_cpu_ids/nr_cpumask_bits.: ia64
Impact: cleanup, futureproof
In fact, all cpumask ops will only be valid (in general) for bit numbers < nr_cpu_ids. S
cpumask: prepare for iterators to only go to nr_cpu_ids/nr_cpumask_bits.: ia64
Impact: cleanup, futureproof
In fact, all cpumask ops will only be valid (in general) for bit numbers < nr_cpu_ids. So use that instead of NR_CPUS in various places.
This is always safe: no cpu number can be >= nr_cpu_ids, and nr_cpu_ids is initialized to NR_CPUS at boot.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Mike Travis <travis@sgi.com> Acked-by: Ingo Molnar <mingo@elte.hu>
show more ...
|
Revision tags: v2.6.29-rc7, v2.6.29-rc6, v2.6.29-rc5, v2.6.29-rc4, v2.6.29-rc3, v2.6.29-rc2, v2.6.29-rc1, v2.6.28, v2.6.28-rc9, v2.6.28-rc8, v2.6.28-rc7, v2.6.28-rc6, v2.6.28-rc5, v2.6.28-rc4 |
|
#
17c1f07e |
| 07-Nov-2008 |
Jay Lan <jlan@sgi.com> |
[IA64] Reserve elfcorehdr memory in CONFIG_CRASH_DUMP
IA64 kdump kernel failed to initialize /proc/vmcore in 2.6.28-rc2. A bug was introduced in this patch commit:
d9a9855d0b06ca6d6cc92596fedcc03
[IA64] Reserve elfcorehdr memory in CONFIG_CRASH_DUMP
IA64 kdump kernel failed to initialize /proc/vmcore in 2.6.28-rc2. A bug was introduced in this patch commit:
d9a9855d0b06ca6d6cc92596fedcc03f8512e062 always reserve elfcore header memory in crash kernel
The problem was that the call to reserve_elfcorehdr() should be placed in CONFIG_CRASH_DUMP rather than in CONFIG_CRASH_KERNEL, which does not exist.
Signed-off-by: Jay Lan <jlan@sgi.com> Acked-by: Simon Hormon <horms@verge.net.au> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
#
62ee0540 |
| 05-Nov-2008 |
Doug Chapman <doug.chapman@hp.com> |
[IA64] fix boot panic caused by offline CPUs
This fixes a regression introduced by 2c6e6db41f01b6b4eb98809350827c9678996698 "Minimize per_cpu reservations." That patch incorrectly used information
[IA64] fix boot panic caused by offline CPUs
This fixes a regression introduced by 2c6e6db41f01b6b4eb98809350827c9678996698 "Minimize per_cpu reservations." That patch incorrectly used information about what CPUs are possible that was not yet initialized by ACPI. The end result was that per_cpu structures for offline CPUs were not initialized causing a NULL pointer reference.
Since we cannot do the full acpi_boot_init() call any earlier, the simplest fix is to just parse the MADT for SAPIC entries early to find the CPU info. This should also allow for some cleanup of the code added by the "Minimize per_cpu reservations". This patch just fixes the regressions, the cleanup will come in a later patch.
Signed-off-by: Doug Chapman <doug.chapman@hp.com> Signed-off-by: Alex Chiang <achiang@hp.com> CC: Robin Holt <holt@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.28-rc3, v2.6.28-rc2, v2.6.28-rc1 |
|
#
d9a9855d |
| 18-Oct-2008 |
Simon Horman <horms@verge.net.au> |
always reserve elfcore header memory in crash kernel
elfcore header memory needs to be reserved in a crash kernel. This means that the relevant code should be protected by CONFIG_CRASH_DUMP rather
always reserve elfcore header memory in crash kernel
elfcore header memory needs to be reserved in a crash kernel. This means that the relevant code should be protected by CONFIG_CRASH_DUMP rather than CONFIG_PROC_VMCORE.
Signed-off-by: Simon Horman <horms@verge.net.au> Cc: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
#
85a0ee34 |
| 18-Oct-2008 |
Simon Horman <horms@verge.net.au> |
kdump: add is_vmcore_usable() and vmcore_unusable()
The usage of elfcorehdr_addr has changed recently such that being set to ELFCORE_ADDR_MAX is used by is_kdump_kernel() to indicate if the code is
kdump: add is_vmcore_usable() and vmcore_unusable()
The usage of elfcorehdr_addr has changed recently such that being set to ELFCORE_ADDR_MAX is used by is_kdump_kernel() to indicate if the code is executing in a kernel executed as a crash kernel.
However, arch/ia64/kernel/setup.c:reserve_elfcorehdr will rest elfcorehdr_addr to ELFCORE_ADDR_MAX on error, which means any subsequent calls to is_kdump_kernel() will return 0, even though they should return 1.
Ok, at this point in time there are no subsequent calls, but I think its fair to say that there is ample scope for error or at the very least confusion.
This patch add an extra state, ELFCORE_ADDR_ERR, which indicates that elfcorehdr_addr was passed on the command line, and thus execution is taking place in a crashdump kernel, but vmcore can't be used for some reason. This is tested for using is_vmcore_usable() and set using vmcore_unusable(). A subsequent patch makes use of this new code.
To summarise, the states that elfcorehdr_addr can now be in are as follows:
ELFCORE_ADDR_MAX: not a crashdump kernel ELFCORE_ADDR_ERR: crashdump kernel but vmcore is unusable any other value: crash dump kernel and vmcore is usable
Signed-off-by: Simon Horman <horms@verge.net.au> Cc: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
#
57cac4d1 |
| 18-Oct-2008 |
Vivek Goyal <vgoyal@redhat.com> |
kdump: make elfcorehdr_addr independent of CONFIG_PROC_VMCORE
o elfcorehdr_addr is used by not only the code under CONFIG_PROC_VMCORE but also by the code which is not inside CONFIG_PROC_VMCORE.
kdump: make elfcorehdr_addr independent of CONFIG_PROC_VMCORE
o elfcorehdr_addr is used by not only the code under CONFIG_PROC_VMCORE but also by the code which is not inside CONFIG_PROC_VMCORE. For example, is_kdump_kernel() is used by powerpc code to determine if kernel is booting after a panic then use previous kernel's TCE table. So even if CONFIG_PROC_VMCORE is not set in second kernel, one should be able to correctly determine that we are booting after a panic and setup calgary iommu accordingly.
o So remove the assumption that elfcorehdr_addr is under CONFIG_PROC_VMCORE.
o Move definition of elfcorehdr_addr to arch dependent crash files. (Unfortunately crash dump does not have an arch independent file otherwise that would have been the best place).
o kexec.c is not the right place as one can Have CRASH_DUMP enabled in second kernel without KEXEC being enabled.
o I don't see sh setup code parsing the command line for elfcorehdr_addr. I am wondering how does vmcore interface work on sh. Anyway, I am atleast defining elfcoredhr_addr so that compilation is not broken on sh.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com> Acked-by: Simon Horman <horms@verge.net.au> Acked-by: Paul Mundt <lethal@linux-sh.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
#
62fdd767 |
| 17-Oct-2008 |
Fenghua Yu <fenghua.yu@intel.com> |
[IA64] Add Variable Page Size and IA64 Support in Intel IOMMU
The patch contains Intel IOMMU IA64 specific code. It defines new machvec dig_vtd, hooks for IOMMU, DMAR table detection, cache line flu
[IA64] Add Variable Page Size and IA64 Support in Intel IOMMU
The patch contains Intel IOMMU IA64 specific code. It defines new machvec dig_vtd, hooks for IOMMU, DMAR table detection, cache line flush function, etc.
For a generic kernel with CONFIG_DMAR=y, if Intel IOMMU is detected, dig_vtd is used for machinve vector. Otherwise, kernel falls back to dig machine vector. Kernel parameter "machvec=dig" or "intel_iommu=off" can be used to force kernel to boot dig machine vector.
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.27, v2.6.27-rc9, v2.6.27-rc8, v2.6.27-rc7 |
|
#
06f95ea8 |
| 16-Sep-2008 |
Alex Chiang <achiang@hp.com> |
[IA64] Ski simulator doesn't need check_sal_cache_flush
Peter Chubb reported that commit 3463a93def55c309f3c0d0a8aaf216be3be42d64 (Update check_sal_cache_flush to use platform_send_ipi()) broke Ski
[IA64] Ski simulator doesn't need check_sal_cache_flush
Peter Chubb reported that commit 3463a93def55c309f3c0d0a8aaf216be3be42d64 (Update check_sal_cache_flush to use platform_send_ipi()) broke Ski because it does not implement IPIs.
Tony Luck suggested we just #ifndef out the call (since the simulator does not have the SAL bug that this code is attempting to detect and workaround)
Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.27-rc6, v2.6.27-rc5, v2.6.27-rc4, v2.6.27-rc3 |
|
#
10617bbe |
| 12-Aug-2008 |
Tony Luck <tony.luck@intel.com> |
[IA64] Ensure cpu0 can access per-cpu variables in early boot code
ia64 handles per-cpu variables a litle differently from other architectures in that it maps the physical memory allocated for each
[IA64] Ensure cpu0 can access per-cpu variables in early boot code
ia64 handles per-cpu variables a litle differently from other architectures in that it maps the physical memory allocated for each cpu at a constant virtual address (0xffffffffffff0000). This mapping is not enabled until the architecture specific cpu_init() function is run, which causes problems since some generic code is run before this point. In particular when CONFIG_PRINTK_TIME is enabled, the boot cpu will trap on the access to per-cpu memory at the first printk() call so the boot will fail without the kernel printing anything to the console.
Fix this by allocating percpu memory for cpu0 in the kernel data section and doing all initialization to enable percpu access in head.S before calling any generic code.
Other cpus must take care not to access per-cpu variables too early, but their code path from start_secondary() to cpu_init() is all in arch/ia64
Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.27-rc2 |
|
#
7f30491c |
| 01-Aug-2008 |
Tony Luck <tony.luck@intel.com> |
[IA64] Move include/asm-ia64 to arch/ia64/include/asm
After moving the the include files there were a few clean-ups:
1) Some files used #include <asm-ia64/xyz.h>, changed to <asm/xyz.h>
2) Some co
[IA64] Move include/asm-ia64 to arch/ia64/include/asm
After moving the the include files there were a few clean-ups:
1) Some files used #include <asm-ia64/xyz.h>, changed to <asm/xyz.h>
2) Some comments alerted maintainers to look at various header files to make matching updates if certain code were to be changed. Updated these comments to use the new include paths.
3) Some header files mentioned their own names in initial comments. Just deleted these self references.
Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.27-rc1, v2.6.26, v2.6.26-rc9 |
|
#
dd4f0888 |
| 30-Jun-2008 |
Tony Luck <tony.luck@intel.com> |
[IA64] Bugfix for system with 32 cpus
On a system where there are no hot pluggable cpus "additional_cpus" is still set to -1 at the point where we call per_cpu_scan_finalize(). If we didn't find an
[IA64] Bugfix for system with 32 cpus
On a system where there are no hot pluggable cpus "additional_cpus" is still set to -1 at the point where we call per_cpu_scan_finalize(). If we didn't find an SRAT table and so pick the default "32" for the number of cpus, when we get to: high_cpu = min(high_cpu + reserve_cpus, NR_CPUS); we will end up initializing for just 31 cpus ... and so we will die horribly when bringing up cpu#32.
Problem introduced by: 2c6e6db41f01b6b4eb98809350827c9678996698 "Minimize per_cpu reservations."
Acked-by: Robin Holt <holt@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.26-rc8 |
|
#
2826f8c0 |
| 24-Jun-2008 |
Jes Sorensen <jes@sgi.com> |
[IA64] Fix boot failure on ia64/sn2
Call check_sal_cache_flush() after platform_setup() as check_sal_cache_flush() now relies on being able to call platform vector code.
Problem was introduced by:
[IA64] Fix boot failure on ia64/sn2
Call check_sal_cache_flush() after platform_setup() as check_sal_cache_flush() now relies on being able to call platform vector code.
Problem was introduced by: 3463a93def55c309f3c0d0a8aaf216be3be42d64 "Update check_sal_cache_flush to use platform_send_ipi()"
Signed-off-by: Jes Sorensen <jes@sgi.com> Tested-by: Alex Chiang: <achiang@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.26-rc7, v2.6.26-rc6, v2.6.26-rc5, v2.6.26-rc4 |
|
#
e51835d5 |
| 19-May-2008 |
Isaku Yamahata <yamahata@valinux.co.jp> |
[IA64] pvops: define initialization hooks, pv_init_ops, for paravirtualized environment.
define pv_init_ops hooks which represents various initialization hooks for paravirtualized environment. and a
[IA64] pvops: define initialization hooks, pv_init_ops, for paravirtualized environment.
define pv_init_ops hooks which represents various initialization hooks for paravirtualized environment. and add hooks.
Signed-off-by: Alex Williamson <alex.williamson@hp.com> Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
#
4dcc29e1 |
| 27-May-2008 |
Tony Luck <tony.luck@intel.com> |
[IA64] Workaround for RSE issue
Problem: An application violating the architectural rules regarding operation dependencies and having specific Register Stack Engine (RSE) state at the time of the vi
[IA64] Workaround for RSE issue
Problem: An application violating the architectural rules regarding operation dependencies and having specific Register Stack Engine (RSE) state at the time of the violation, may result in an illegal operation fault and invalid RSE state. Such faults may initiate a cascade of repeated illegal operation faults within OS interruption handlers. The specific behavior is OS dependent.
Implication: An application causing an illegal operation fault with specific RSE state may result in a series of illegal operation faults and an eventual OS stack overflow condition.
Workaround: OS interruption handlers that switch to kernel backing store implement a check for invalid RSE state to avoid the series of illegal operation faults.
The core of the workaround is the RSE_WORKAROUND code sequence inserted into each invocation of the SAVE_MIN_WITH_COVER and SAVE_MIN_WITH_COVER_R19 macros. This sequence includes hard-coded constants that depend on the number of stacked physical registers being 96. The rest of this patch consists of code to disable this workaround should this not be the case (with the presumption that if a future Itanium processor increases the number of registers, it would also remove the need for this patch).
Move the start of the RBS up to a mod32 boundary to avoid some corner cases.
The dispatch_illegal_op_fault code outgrew the spot it was squatting in when built with this patch and CONFIG_VIRT_CPU_ACCOUNTING=y Move it out to the end of the ivt.
Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.26-rc3 |
|
#
8a3360f0 |
| 14-May-2008 |
Bernhard Walle <bwalle@suse.de> |
[IA64] Don't reserve crashkernel memory > 4 GB
Some IA64 machines map all cell-local memory above 4 GB (32 bit limit). However, in most cases, the kernel needs some memory below that limit that is D
[IA64] Don't reserve crashkernel memory > 4 GB
Some IA64 machines map all cell-local memory above 4 GB (32 bit limit). However, in most cases, the kernel needs some memory below that limit that is DMA-capable. So in this machine configuration, the crashkernel will be reserved above 4 GB.
For machines that use SWIOTLB implementation because they lack an I/O MMU the low memory is required by the SWIOTLB implementation. In that case, it doesn't make sense to reserve the crashkernel at all because it's unusable for kdump.
A special case is the "hpzx1" machine vector. In theory, it has a I/O MMU, so it can be booted above 4 GB. However, in the kdump case that is not possible because of changeset 51b58e3e26ebfb8cd56825c4b396ed251f51dec9:
On HP zx1 machines, the 'machvec=dig' parameter is needed for the kdump kernel to avoid problems with the HP sba iommu. The problem is that during the boot of the kdump kernel, the iommu is re-initialized, so in-flight DMA from improperly shutdown drivers causes an IOTLB miss which leads to an MCA. With kdump, the idea is to get into the kdump kernel with as little code as we can, so shutting down drivers properly is not an option.
The workaround is to add 'machvec=dig' to the kdump kernel boot parameters. This makes the kdump kernel avoid using the sba iommu altogether, leaving the IOTLB intact. Any ongoing DMA falls harmlessly outside the kdump kernel. After the kdump kernel reboots, all devices will have been shutdown properly and DMA stopped.
This patch pushes that functionality into the sba iommu initialization code, so that users won't have to find the obscure documentation telling them about 'machvec=dig'.
This means that also for hpzx1 it's not possible to boot when all memory is above the 4 GB limit. So the only machine vectors that can handle this case are "sn2" and "uv".
Signed-off-by: Bernhard Walle <bwalle@suse.de> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.26-rc2, v2.6.26-rc1, v2.6.25 |
|
#
98075d24 |
| 11-Apr-2008 |
Zoltan Menyhart <Zoltan.Menyhart@bull.net> |
[IA64] Fix NUMA configuration issue
There is a NUMA memory configuration issue in 2.6.24:
A 2-node machine of ours has got the following memory layout:
Node 0: 0 - 2 Gbytes Node 0: 4 - 8 Gbytes No
[IA64] Fix NUMA configuration issue
There is a NUMA memory configuration issue in 2.6.24:
A 2-node machine of ours has got the following memory layout:
Node 0: 0 - 2 Gbytes Node 0: 4 - 8 Gbytes Node 1: 8 - 16 Gbytes Node 0: 16 - 18 Gbytes
"efi_memmap_init()" merges the three last ranges into one.
"register_active_ranges()" is called as follows:
efi_memmap_walk(register_active_ranges, NULL);
i.e. once for the 4 - 18 Gbytes range. It picks up the node number from the start address, and registers all the memory for the node #0.
"register_active_ranges()" should be called as follows to make sure there is no merged address range at its entry:
efi_memmap_walk(filter_memory, register_active_ranges);
"filter_memory()" is similar to "filter_rsvd_memory()", but the reserved memory ranges are not filtered out.
Signed-off-by: Zoltan Menyhart <Zoltan.Menyhart@bull.net> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.25-rc9 |
|
#
2c6e6db4 |
| 03-Apr-2008 |
holt@sgi.com <holt@sgi.com> |
[IA64] Minimize per_cpu reservations.
This attached patch significantly shrinks boot memory allocation on ia64. It does this by not allocating per_cpu areas for cpus that can never exist.
In the ca
[IA64] Minimize per_cpu reservations.
This attached patch significantly shrinks boot memory allocation on ia64. It does this by not allocating per_cpu areas for cpus that can never exist.
In the case where acpi does not have any numa node description of the cpus, I defaulted to assigning the first 32 round-robin on the known nodes.. For the !CONFIG_ACPI I used for_each_possible_cpu().
Signed-off-by: Robin Holt <holt@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|