532bfc851a7475fb6a36c1e953aa395798a7cca7 |
|
29-Mar-2012 |
Linus Torvalds <torvalds@linux-foundation.org> |
Merge branch 'akpm' (Andrew's patch-bomb) Merge third batch of patches from Andrew Morton: - Some MM stragglers - core SMP library cleanups (on_each_cpu_mask) - Some IPI optimisations - kexec - kdump - IPMI - the radix-tree iterator work - various other misc bits. "That'll do for -rc1. I still have ~10 patches for 3.4, will send those along when they've baked a little more." * emailed from Andrew Morton <akpm@linux-foundation.org>: (35 commits) backlight: fix typo in tosa_lcd.c crc32: add help text for the algorithm select option mm: move hugepage test examples to tools/testing/selftests/vm mm: move slabinfo.c to tools/vm mm: move page-types.c from Documentation to tools/vm selftests/Makefile: make `run_tests' depend on `all' selftests: launch individual selftests from the main Makefile radix-tree: use iterators in find_get_pages* functions radix-tree: rewrite gang lookup using iterator radix-tree: introduce bit-optimized iterator fs/proc/namespaces.c: prevent crash when ns_entries[] is empty nbd: rename the nbd_device variable from lo to nbd pidns: add reboot_pid_ns() to handle the reboot syscall sysctl: use bitmap library functions ipmi: use locks on watchdog timeout set on reboot ipmi: simplify locking ipmi: fix message handling during panics ipmi: use a tasklet for handling received messages ipmi: increase KCS timeouts ipmi: decrease the IPMI message transaction time in interrupt mode ...
|
7d7f98488b203cbf78538698cf5d937f670d96d3 |
|
28-Mar-2012 |
Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> |
arch/ia64: remove references to cpu_*_map This was marked as obsolete for quite a while now.. Now it is time to remove it altogether. And while doing this, get rid of first_cpu() as well. Also, remove the redundant setting of cpu_online_mask in smp_prepare_cpus() because the generic code would have already set cpu 0 in cpu_online_mask. Reported-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
/arch/ia64/kernel/setup.c
|
c140d87995b68b428f70635c2e4071e4e8b3256e |
|
28-Mar-2012 |
David Howells <dhowells@redhat.com> |
Disintegrate asm/system.h for IA64 Disintegrate asm/system.h for IA64. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Tony Luck <tony.luck@intel.com> cc: linux-ia64@vger.kernel.org
/arch/ia64/kernel/setup.c
|
76d71ebddf23e8195dd5f7889cb2844530689907 |
|
29-Nov-2011 |
Petr Tesarik <ptesarik@suse.cz> |
[IA64] Merge overlapping reserved regions at boot While working on the upcoming SLES11 SP2, I ran into an issue with booting the panic kernel on a kernel crash. In the first iteration I found out that the initial register backing store gets overwritten with zeroes, causing a kernel crash shortly afterwards. Further investigation revealed that rsvd_region[] contains overlapping entries: find_memmap_space() returns a pointer which lies between KERNEL_START and _end. This is correct with the EFI memmap as patched by the kexec purgatory code. That code removes vmlinux LOAD segments from the usable map, but there is a pretty large hole between the gate section and the per-cpu section. This happens because reserve_memory() blindly marks [KERNEL_START, __end] as reserved, even though there is a free block in the middle in the kexec case because it noticed a large gap between sections and modified the efi_memory_map to account for this. Signed-off-by: Petr Tesarik <ptesarik@suse.cz> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
93a72052be81823fa1584b9be037d51924f9efa4 |
|
24-Mar-2011 |
Olaf Hering <olaf@aepfle.de> |
crash_dump: export is_kdump_kernel to modules, consolidate elfcorehdr_addr, setup_elfcorehdr and saved_max_pfn The Xen PV drivers in a crashed HVM guest can not connect to the dom0 backend drivers because both frontend and backend drivers are still in connected state. To run the connection reset function only in case of a crashdump, the is_kdump_kernel() function needs to be available for the PV driver modules. Consolidate elfcorehdr_addr, setup_elfcorehdr and saved_max_pfn into kernel/crash_dump.c Also export elfcorehdr_addr to make is_kdump_kernel() usable for modules. Leave 'elfcorehdr' as early_param(). This changes powerpc from __setup() to early_param(). It adds an address range check from x86 also on ia64 and powerpc. [akpm@linux-foundation.org: additional #includes] [akpm@linux-foundation.org: remove elfcorehdr_addr export] [akpm@linux-foundation.org: fix for Tejun's mm/nobootmem.c changes] Signed-off-by: Olaf Hering <olaf@aepfle.de> Cc: Russell King <rmk@arm.linux.org.uk> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mundt <lethal@linux-sh.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
/arch/ia64/kernel/setup.c
|
4de0a7594823d04361281e34e59f2c1108899f3e |
|
06-Oct-2010 |
Tony Luck <tony.luck@intel.com> |
[IA64] Initialize interrupts later (from init_IRQ()) Thomas Gleixner is cleaning up the generic irq code, and ia64 ran into problems because it calls register_intr() before early_irq_init() is called. Move the call to acpi_boot_init() from setup_arch() to init_IRQ(). As a bonus - moving the call later means we no longer need the hacks in iosapic.c to switch between the bootmem and regular allocator - we can just used kzalloc() for allocation. Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
4565f0170dfc849b3629c27d769db800467baa62 |
|
11-Aug-2010 |
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> |
dma-mapping: unify dma_get_cache_alignment implementations dma_get_cache_alignment returns the minimum DMA alignment. Architectures defines it as ARCH_DMA_MINALIGN (formally ARCH_KMALLOC_MINALIGN). So we can unify dma_get_cache_alignment implementations. Note that some architectures implement dma_get_cache_alignment wrongly. dma_get_cache_alignment() should return the minimum DMA alignment. So fully-coherent architectures should return 1. This patch also fixes this issue. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: <linux-arch@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
/arch/ia64/kernel/setup.c
|
32974ad4907cdde6c9de612cd1b2ee0568fb9409 |
|
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 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>
/arch/ia64/kernel/setup.c
|
877105cc49f6e6ad32e3d63a214e8f537c0339ef |
|
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 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
/arch/ia64/kernel/setup.c
|
52594762a39dfb6338c9d0906ca21dd9ae9453be |
|
02-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 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>
/arch/ia64/kernel/setup.c
|
12cda817779ce5381a9a4ba8d464abe17c50a9e2 |
|
02-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 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>
/arch/ia64/kernel/setup.c
|
872fb6dd6b07986417964e089074e7acfd025f4c |
|
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 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>
/arch/ia64/kernel/setup.c
|
e088a4ad7fa53c3dc3c29f930025f41ccf01953e |
|
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 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>
/arch/ia64/kernel/setup.c
|
80a03e29164c76b70e6dbb1d10515820cc24487a |
|
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>
/arch/ia64/kernel/setup.c
|
c66b31f3926165bc1d4128adc97a064dcbab421a |
|
31-Mar-2009 |
Tony Luck <aegl@agluck-desktop.(none)> |
Pull pvops into release branch
|
03f511dd02f1431ef652fb97a7f2fe7aef47e025 |
|
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 into inline execution or direct call. Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
5dd3c9949a3e92ea7fd8c75d888031f7aff1f1d0 |
|
16-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. 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>
/arch/ia64/kernel/setup.c
|
17c1f07ed70afa4f3941745fc3cc173e2a0365fe |
|
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: 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>
/arch/ia64/kernel/setup.c
|
62ee0540f5e5a804b79cae8b3c0185a85f02436b |
|
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 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>
/arch/ia64/kernel/setup.c
|
72441bdc76f7f71d7b75cdaa48f26dbb1f3d932e |
|
23-Oct-2008 |
Linus Torvalds <torvalds@linux-foundation.org> |
Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6 * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6: (41 commits) [IA64] Fix annoying IA64_TR_ALLOC_MAX message. [IA64] kill sys32_pipe [IA64] remove sys32_pause [IA64] Add Variable Page Size and IA64 Support in Intel IOMMU ia64/pv_ops: paravirtualized instruction checker. ia64/xen: a recipe for using xen/ia64 with pv_ops. ia64/pv_ops: update Kconfig for paravirtualized guest and xen. ia64/xen: preliminary support for save/restore. ia64/xen: define xen machine vector for domU. ia64/pv_ops/xen: implement xen pv_time_ops. ia64/pv_ops/xen: implement xen pv_irq_ops. ia64/pv_ops/xen: define the nubmer of irqs which xen needs. ia64/pv_ops/xen: implement xen pv_iosapic_ops. ia64/pv_ops/xen: paravirtualize entry.S for ia64/xen. ia64/pv_ops/xen: paravirtualize ivt.S for xen. ia64/pv_ops/xen: paravirtualize DO_SAVE_MIN for xen. ia64/pv_ops/xen: define xen paravirtualized instructions for hand written assembly code ia64/pv_ops/xen: define xen pv_cpu_ops. ia64/pv_ops/xen: define xen pv_init_ops for various xen initialization. ia64/pv_ops/xen: elf note based xen startup. ...
|
d9a9855d0b06ca6d6cc92596fedcc03f8512e062 |
|
19-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 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>
/arch/ia64/kernel/setup.c
|
85a0ee342e0c06c19d78fdf48307211c6cf18fcb |
|
19-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 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>
/arch/ia64/kernel/setup.c
|
57cac4d1880527e0baf6c2fda529d2ad1d815aec |
|
19-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. 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>
/arch/ia64/kernel/setup.c
|
62fdd7678a26efadd6ac5c2869543caff77d2df0 |
|
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 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>
/arch/ia64/kernel/setup.c
|
06f95ea8988513b172080c419e4be8826c55a318 |
|
17-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 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>
/arch/ia64/kernel/setup.c
|
10617bbe84628eb18ab5f723d3ba35005adde143 |
|
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 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>
/arch/ia64/kernel/setup.c
|
7f30491ccd28627742e37899453ae20e3da8e18f |
|
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 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>
/arch/ia64/kernel/setup.c
|
fca515fbfa5ecd9f7b54db311317e2c877d7831a |
|
17-Jul-2008 |
Tony Luck <tony.luck@intel.com> |
Pull pvops into release branch
|
dd4f0888f8b42a97c93a66617a4f9acaff3089d6 |
|
01-Jul-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 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>
/arch/ia64/kernel/setup.c
|
2826f8c0f4c97b7db33e2a680f184d828eb7a785 |
|
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: 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>
/arch/ia64/kernel/setup.c
|
e51835d58a5abdf82211f36f500f666ca7ef9aee |
|
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 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>
/arch/ia64/kernel/setup.c
|
4dcc29e1574d88f4465ba865ed82800032f76418 |
|
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 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>
/arch/ia64/kernel/setup.c
|
8a3360f06cd4d3b1d57f73e029f2f8b6057fdcba |
|
15-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 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>
/arch/ia64/kernel/setup.c
|
71b264f85ff50c14fe945ffff06ae0d5e9a9124e |
|
17-Apr-2008 |
Tony Luck <tony.luck@intel.com> |
Pull miscellaneous into release branch Conflicts: arch/ia64/kernel/mca.c
|
f4df39cbdd9e9ab615e80148cc271db22a8508ad |
|
17-Apr-2008 |
Tony Luck <tony.luck@intel.com> |
Pull nptcg into release branch Conflicts: arch/ia64/mm/tlb.c
|
98075d245a5bc4aeebc2e9f16fa8b089a5c200ac |
|
12-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 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>
/arch/ia64/kernel/setup.c
|
2c6e6db41f01b6b4eb98809350827c9678996698 |
|
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 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>
/arch/ia64/kernel/setup.c
|
a6c75b86ce9f01db4ea9912877b526c2dc4d2f0a |
|
14-Mar-2008 |
Fenghua Yu <fenghua.yu@intel.com> |
[IA64] Kernel parameter for max number of concurrent global TLB purges The patch defines kernel parameter "nptcg=". The parameter overrides max number of concurrent global TLB purges which is reported from either PAL_VM_SUMMARY or SAL PALO. Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
2046b94e7c4fce92eb8165c2c36c6478f4927178 |
|
04-Apr-2008 |
Fenghua Yu <fenghua.yu@intel.com> |
[IA64] Multiple outstanding ptc.g instruction support According to SDM2.2, Itanium supports multiple outstanding ptc.g instructions. But current kernel function ia64_global_tlb_purge() uses a spinlock to serialize ptc.g instructions issued by multiple processors. This serialization might have scalability issue on a big SMP machine where many processors could purge TLB in parallel. The patch fixes this problem by issuing multiple ptc.g instructions in ia64_global_tlb_purge(). It also adds support for the "PALO" table to get a platform view of the max number of outstanding ptc.g instructions (which may be different from the processor view found from PAL_VM_SUMMARY). PALO specification can be found at: http://www.dig64.org/home/DIG64_PALO_R1_0.pdf spinaphore implementation by Matthew Wilcox. Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
d4ed80841ad4a1d59decccfbe2d010558568c5fb |
|
05-Mar-2008 |
Harvey Harrison <harvey.harrison@gmail.com> |
[IA64] remove remaining __FUNCTION__ occurrences __FUNCTION__ is gcc-specific, use __func__ Long lines have been kept where they exist, some small spacing changes have been done. Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
a23fe55e132cd85108ab55b3fafb4b5060d847c7 |
|
22-Jan-2008 |
Jan Engelhardt <jengelh@computergmbh.de> |
[IA64] constify function pointer tables Signed-off-by: Jan Engelhardt <jengelh@computergmbh.de> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
86faf39d0fc04272b05fab1db6d683f3ac7199d1 |
|
25-Jan-2008 |
Ingo Molnar <mingo@elte.hu> |
sched: remove printk_clock references from ia64 remove remaining printk_clock references from ia64. Signed-off-by: Ingo Molnar <mingo@elte.hu>
/arch/ia64/kernel/setup.c
|
b898a424ed68ba73d6d4562d6370985b2e9bec61 |
|
21-Nov-2007 |
Bernhard Walle <bwalle@suse.de> |
[IA64] rename _bss to __bss_start Rename _bss to __bss_start as on other architectures. That makes it possible to use the <linux/sections.h> instead of own declarations. Also add __bss_stop because that symbol exists on other architectures. Signed-off-by: Bernhard Walle <bwalle@suse.de> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
113134fcbca83619be4c68d0ca66db6093777b5d |
|
19-Oct-2007 |
Alex Chiang <achiang@hp.com> |
[IA64] /proc/cpuinfo "physical id" field cleanups Clean up the process for presenting the "physical id" field in /proc/cpuinfo. - remove global smp_num_cpucores, as it is mostly useless - remove check_for_logical_procs(), since we do the same functionality in identify_siblings() - reflow logic in identify_siblings(). If an older CPU does not implement PAL_LOGICAL_TO_PHYSICAL, we may still be able to get useful information from SAL_PHYSICAL_ID_INFO - in identify_siblings(), threads/cores are a property of the CPU, not the platform - remove useless printk's about multi-core / thread capability in identify_siblings(), as that information is readily available in /proc/cpuinfo, and printing for the BSP only adds little value - smp_num_siblings is now meaningful if any CPU in the system supports threads, not just the BSP - expose "physical id" field, even on CPUs that are not multi-core / multi-threaded (as long as we have a valid value). Now we know what sockets Madisons live in too. Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
00bf4098beb15ca174b54f3af1f1e1908d7d18a3 |
|
22-Oct-2007 |
Bernhard Walle <bwalle@suse.de> |
kexec: add BSS to resource tree Add the BSS to the resource tree just as kernel text and kernel data are in the resource tree. The main reason behind this is to avoid crashkernel reservation in that area. While it's not strictly necessary to have the BSS in the resource tree (the actual collision detection is done in the reserve_bootmem() function before), the usage of the BSS resource should be presented to the user in /proc/iomem just as Kernel data and Kernel code. Note: The patch currently is only implemented for x86 and ia64 (because efi_initialize_iomem_resources() has the same signature on i386 and ia64). [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Bernhard Walle <bwalle@suse.de> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Vivek Goyal <vgoyal@in.ibm.com> Cc: <linux-arch@vger.kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
/arch/ia64/kernel/setup.c
|
cb3808532eeb1719667356157fac9222ccb2c4ff |
|
19-Oct-2007 |
Bernhard Walle <bwalle@suse.de> |
Use extended crashkernel command line on ia64 This patch adapts IA64 to use the generic parse_crashkernel() function instead of its own parsing for the crashkernel command line. Because the total amount of System RAM must be known when calling this function, efi_memmap_init() is modified to return its accumulated total_memory variable. Also, the crashkernel handling is moved in an own function in arch/ia64/kernel/setup.c to make the code more readable. [kamalesh@linux.vnet.ibm.com: build fix] Signed-off-by: Bernhard Walle <bwalle@suse.de> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Vivek Goyal <vgoyal@in.ibm.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
/arch/ia64/kernel/setup.c
|
4d1efed540df1ccd3077df6f2bffba9d506b7d7b |
|
16-Oct-2007 |
Tony Luck <tony.luck@intel.com> |
[IA64] Fix build for CONFIG_SMP=n d5a7430ddcdb598261d70f7eb1bf450b5be52085 missed a spot where we use cpu_sibling_map and cpu_core_map. These don't exist on a uni-processor build. Wrap #ifdef CONFIG_SMP ... #endif around it. Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
d5a7430ddcdb598261d70f7eb1bf450b5be52085 |
|
16-Oct-2007 |
Mike Travis <travis@sgi.com> |
Convert cpu_sibling_map to be a per cpu variable Convert cpu_sibling_map from a static array sized by NR_CPUS to a per_cpu variable. This saves sizeof(cpumask_t) * NR unused cpus. Access is mostly from startup and CPU HOTPLUG functions. Signed-off-by: Mike Travis <travis@sgi.com> Cc: Andi Kleen <ak@suse.de> Cc: Christoph Lameter <clameter@sgi.com> Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
/arch/ia64/kernel/setup.c
|
8b713c67bccef7cabb0ee915f47eb33d82636af9 |
|
21-Aug-2007 |
Peter Chubb <peterc@chubb.wattle.id.au> |
[IA64] Enable early console for Ski simulator This patch cleans up the `enable early console for SKI' patch (471e7a44848f467c9b83adc3463d019d2fa8817f), and 1. potentially allows the gensparse_defconfig to work again. (there are other problems running a generic kernel on Ski) 2. fixes the `console registered twice' problem. 3. Cleans up the code by moving the `extern hpsim_cons' declaration to a new asm/hpsim.h file. Thanks to Jes for comments. Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
f740e6c9c55cac6ab0a7d44a464b54467cca4f4f |
|
22-Aug-2007 |
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> |
[IA64] Clear pending interrupts at CPU boot up time The pending interrupts can be remaining at boot up time on some platform. This will cause spurious interrupts when interrupt is enabled for the first time. This patch clears IVR at the CPU initialization to eliminate such spurious interrupts. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
471e7a44848f467c9b83adc3463d019d2fa8817f |
|
16-Aug-2007 |
Peter Chubb <peterc@gelato.unsw.edu.au> |
[IA64] Enable early console for Ski simulator When using Ski to debug early startup, it's a bit of a pain not to have printk. This patch enables the simulated console very early. It may be worth conditionalising on the command line... but this is enough for now. Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
1b30859b8d42b3161954a81da7f96055a4617220 |
|
30-Jul-2007 |
Jesper Juhl <jesper.juhl@gmail.com> |
[IA64] Remove a few duplicate includes This patch removes a few duplicate includes from arch/ia64/ Acked-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
a07ee86205808d36973440e68c7277f9ed63b87f |
|
25-Jul-2007 |
Horms <horms@verge.net.au> |
[IA64] Ensure that machvec is set up takes place before serial console Parse the machvec command line option outside of the early_param() so that ia64_mv is set before any console intialisation that may result from early_param parsing. Signed-off-by: Simon Horman <horms@verge.net.au> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
c41917df8a1adde34864116ce2231a7fe308d2ff |
|
19-Jul-2007 |
Ralf Baechle <ralf@linux-mips.org> |
[PATCH] sched: sched_cacheflush is now unused Since Ingo's recent scheduler rewrite which was merged as commit 0437e109e1841607f2988891eaa36c531c6aa6ac sched_cacheflush is unused. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
/arch/ia64/kernel/setup.c
|
18a8bd949d6adb311ea816125ff65050df1f3f6e |
|
16-Jul-2007 |
Yinghai Lu <Yinghai.Lu@Sun.COM> |
serial: convert early_uart to earlycon for 8250 Beacuse SERIAL_PORT_DFNS is removed from include/asm-i386/serial.h and include/asm-x86_64/serial.h. the serial8250_ports need to be probed late in serial initializing stage. the console_init=>serial8250_console_init=> register_console=>serial8250_console_setup will return -ENDEV, and console ttyS0 can not be enabled at that time. need to wait till uart_add_one_port in drivers/serial/serial_core.c to call register_console to get console ttyS0. that is too late. Make early_uart to use early_param, so uart console can be used earlier. Make it to be bootconsole with CON_BOOT flag, so can use console handover feature. and it will switch to corresponding normal serial console automatically. new command line will be: console=uart8250,io,0x3f8,9600n8 console=uart8250,mmio,0xff5e0000,115200n8 or earlycon=uart8250,io,0x3f8,9600n8 earlycon=uart8250,mmio,0xff5e0000,115200n8 it will print in very early stage: Early serial console at I/O port 0x3f8 (options '9600n8') console [uart0] enabled later for console it will print: console handover: boot [uart0] -> real [ttyS0] Signed-off-by: <yinghai.lu@sun.com> Cc: Andi Kleen <ak@suse.de> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Gerd Hoffmann <kraxel@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
/arch/ia64/kernel/setup.c
|
0437e109e1841607f2988891eaa36c531c6aa6ac |
|
09-Jul-2007 |
Ingo Molnar <mingo@elte.hu> |
sched: zap the migration init / cache-hot balancing code the SMP load-balancer uses the boot-time migration-cost estimation code to attempt to improve the quality of balancing. The reason for this code is that the discrete priority queues do not preserve the order of scheduling accurately, so the load-balancer skips tasks that were running on a CPU 'recently'. this code is fundamental fragile: the boot-time migration cost detector doesnt really work on systems that had large L3 caches, it caused boot delays on large systems and the whole cache-hot concept made the balancing code pretty undeterministic as well. (and hey, i wrote most of it, so i can say it out loud that it sucks ;-) under CFS the same purpose of cache affinity can be achieved without any special cache-hot special-case: tasks are sorted in the 'timeline' tree and the SMP balancer picks tasks from the left side of the tree, thus the most cache-cold task is balanced automatically. Signed-off-by: Ingo Molnar <mingo@elte.hu>
/arch/ia64/kernel/setup.c
|
72fdbdce3d52282f8ea95f512e871791256754e6 |
|
11-May-2007 |
Simon Arlott <simon@fire.lp0.eu> |
[IA64] spelling fixes: arch/ia64/ Spelling and apostrophe fixes in arch/ia64/. Signed-off-by: Simon Arlott <simon@fire.lp0.eu> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
0f7ac29e594808eaddb61f17dcd503ad36b3d769 |
|
07-May-2007 |
Tony Luck <tony.luck@intel.com> |
[IA64] Fix some section mismatch errors Section mismatch: reference to ... .init.text:prefill_possible_map from .text between 'setup_per_cpu_areas' and 'cpu_init' .init.text:iosapic_override_isa_irq from .text between 'iosapic_init' and 'iosapic_remove' Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
b643b0fdbc59cf6bbb086974b29d2571e9e9f646 |
|
30-Apr-2007 |
Tony Luck <tony.luck@intel.com> |
Pull percpu-dtc into release branch
|
8a3a78d1498c4c13c3ec235a4b6338624b6ef68d |
|
06-Apr-2007 |
Venki Pallipadi <venkatesh.pallipadi@intel.com> |
[IA64] Fix CPU freq displayed in /proc/cpuinfo My patch: git commit=95235ca2c20ac0b31a8eb39e2d599bcc3e9c9a10 introduced a bug in IA64 cpuinfo output. Patch changed the proc_freq from 1HZ resolution to 1KHz resolution, but left format string unchanged at " %lu.%06lu". Below is the fix. Thanks to Bjorn for catching this. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
c5e83e3f42938c0a84047e125edb98d6513f985b |
|
12-Mar-2007 |
Jack Steiner <steiner@sgi.com> |
[IA64] Fix get_model_name() for mixed cpu type systems If a system consists of mixed processor types, kmalloc() can be called before the per-cpu data page is initialized. If the slab contains sufficient memory, then kmalloc() works ok. However, if the slabs are empty, slab calls the memory allocator. This requires per-cpu data (NODE_DATA()) & the cpu dies. Also noted by Russ Anderson who had a very similar patch. Signed-off-by: Jack Steiner <steiner@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
ddbad076303dfc0ed4fcba53907dc175bb6d67b2 |
|
06-Mar-2007 |
Horms <horms@verge.net.au> |
[IA64] remove duplicate declaration of efi_initialize_iomem_resources efi_initialize_iomem_resources() is declared in both include/linux/efi.h and arch/ia64/kernel/setup.c. This patch removes the latter. Signed-off-by: Simon Horman <horms@verge.net.au> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
cee87af2a5f75713b98d3e65e43872e547122cd5 |
|
06-Mar-2007 |
Magnus Damm <magnus@valinux.co.jp> |
[IA64] kexec: Use EFI_LOADER_DATA for ELF core header The address where the ELF core header is stored is passed to the secondary kernel as a kernel command line option. The memory area for this header is also marked as a separate EFI memory descriptor on ia64. The separate EFI memory descriptor is at the moment of the type EFI_UNUSABLE_MEMORY. With such a type the secondary kernel skips over the entire memory granule (config option, 16M or 64M) when detecting memory. If we are lucky we will just lose some memory, but if we happen to have data in the same granule (such as an initramfs image), then this data will never get mapped and the kernel bombs out when trying to access it. So this is an attempt to fix this by changing the EFI memory descriptor type into EFI_LOADER_DATA. This type is the same type used for the kernel data and for initramfs. In the secondary kernel we then handle the ELF core header data the same way as we handle the initramfs image. This patch contains the kernel changes to make this happen. Pretty straightforward, we reserve the area in reserve_memory(). The address for the area comes from the kernel command line and the size comes from the specialized EFI parsing function vmcore_find_descriptor_size(). The kexec-tools-testing code for this can be found here: http://lists.osdl.org/pipermail/fastboot/2007-February/005983.html Signed-off-by: Magnus Damm <magnus@valinux.co.jp> Cc: Simon Horman <horms@verge.net.au> Cc: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
a8d91b8477aa433ee0131b031d782411976e1726 |
|
12-Feb-2007 |
Alon Bar-Lev <alon.barlev@gmail.com> |
[PATCH] Dynamic kernel command-line: ia64 1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata. [akpm@osdl.org: move some declarations to the right place] Signed-off-by: Alon Bar-Lev <alon.barlev@gmail.com> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
/arch/ia64/kernel/setup.c
|
a0776ec8e97bf109e7d973d09fc3e1814eb32bfb |
|
13-Oct-2006 |
Chen, Kenneth W <kenneth.w.chen@intel.com> |
[IA64] remove per-cpu ia64_phys_stacked_size_p8 It's not efficient to use a per-cpu variable just to store how many physical stack register a cpu has. Ever since the incarnation of ia64 up till upcoming Montecito processor, that variable has "glued" to 96. Having a variable in memory means that the kernel is burning an extra cacheline access on every syscall and kernel exit path. Such "static" value is better served with the instruction patching utility exists today. Convert ia64_phys_stacked_size_p8 into dynamic insn patching. This also has a pleasant side effect of eliminating access to per-cpu area while psr.ic=0 in the kernel exit path. (fixable for per-cpu DTC work, but why bother?) There are some concerns with the default value that the instruc- tion encoded in the kernel image. It shouldn't be concerned. The reasons are: (1) cpu_init() is called at CPU initialization. In there, we find out physical stack register size from PAL and patch two instructions in kernel exit code. The code in question can not be executed before the patching is done. (2) current implementation stores zero in ia64_phys_stacked_size_p8, and that's what the current kernel exit path loads the value with. With the new code, it is equivalent that we store reg size 96 in ia64_phys_stacked_size_p8, thus creating a better safety net. Given (1) above can never fail, having (2) is just a bonus. All in all, this patch allow one less memory reference in the kernel exit path, thus reducing syscall and interrupt return latency; and avoid polluting potential useful data in the CPU cache. Signed-off-by: Ken Chen <kenneth.w.chen@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
ae0af3e3462fdada42deba30479aba70c6cf8b72 |
|
05-Feb-2007 |
Aron Griffis <aron@hp.com> |
[IA64] use snprintf() on features field of /proc/cpuinfo Some patches have turned up on xen-devel recently to convert strcpy() to safer alternatives and so forth. While reviewing those patches I noticed that the features string building could be cleaned up. This patch uses snprintf() instead of strcpy() and direct character pointer manipulation. It makes the features string building safe and gets rid of the special case for features output in show_cpuinfo() Additionally I removed the (int) cast of ARRAY_SIZE, which seems to serve no purpose. Signed-off-by: Aron Griffis <aron@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
75f6a1de41f90543792403bf0ffb3ead59d0d8cc |
|
12-Dec-2006 |
Tony Luck <tony.luck@intel.com> |
[IA64] Take defensive stance on ia64_pal_get_brand_info() Stephane thought he saw a problem here (but was just confused by the return value from ia64_pal_get_brand_info()). But we should be more defensive here in case an prototype PAL for a future processor doesn't implement this PAL call. Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
ad1c3ba7e54fc38b119c1a7d5c98f9ffb8227fdb |
|
12-Dec-2006 |
Horms <horms@verge.net.au> |
[IA64] Kexec/Kdump: honour non-zero crashkernel offset. There seems to be a value in both allowing the kernel to determine the base offset of the crashkernel automatically and allowing users's to sepcify it. The old behaviour on ia64, which is still the current behaviour on most architectures is for the user to always specify the address. Recently ia64 was changed so that it is always automatically determined. With this patch the kernel automatically determines the offset if the supplied value is 0, otherwise it uses the value provided. This should probably be backed by a documentation change. Signed-Off-By: Simon Horman <horms@verge.net.au> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
45a98fc622ae700eed34eb2be00743910d50dbe1 |
|
12-Dec-2006 |
Horms <horms@verge.net.au> |
[IA64] CONFIG_KEXEC/CONFIG_CRASH_DUMP permutations Actually, on reflection I think that there is a good case for keeping the options separate. I am thinking particularly of people who want a very small crashdump kernel and thus don't want to compile in kexec. The patch below should fix things up so that all valid combinations of KEXEC, CRASH_DUMP and VMCORE compile cleanly - VMCORE depends on CRASH_DUMP which is why I said valid combinations. In a nutshell it just untangles unrelated code and switches around a few defines. Please note that it creats a new file, arch/ia64/kernel/crash_dump.c This is in keeping with the i386 implementation. Signed-off-by: Simon Horman <horms@verge.net.au> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
a79561134f38de12dce14ed72138f38e55ef53fc |
|
07-Dec-2006 |
Zou Nan hai <nanhai.zou@intel.com> |
[IA64] IA64 Kexec/kdump Changes and updates. 1. Remove fake rendz path and related code according to discuss with Khalid Aziz. 2. fc.i offset fix in relocate_kernel.S. 3. iospic shutdown code eoi and mask race fix from Fujitsu. 4. Warm boot hook in machine_kexec to SN SAL code from Jack Steiner. 5. Send slave to SAL slave loop patch from Jay Lan. 6. Kdump on non-recoverable MCA event patch from Jay Lan 7. Use CTL_UNNUMBERED in kdump_on_init sysctl. Signed-off-by: Zou Nan hai <nanhai.zou@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
fa1d19e5d9a94120f31e5783ab44758f46892d94 |
|
25-Oct-2006 |
Troy Heber <troy.heber@hp.com> |
[IA64] move SAL_CACHE_FLUSH check later in boot The check to see if the firmware drops interrupts during a SAL_CACHE_FLUSH is done to early in the boot. SAL_CACHE_FLUSH expects to be able to make PAL calls in virtual mode, on some cell based machines a fault occurs causing a MCA. This patch moves the check after mmu_context_init so the TLB and VHPT are properly setup. Signed-off-by Troy Heber <troy.heber@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
bcf5111a58c7db968c3fb9cd77e340a5e076f549 |
|
30-Aug-2006 |
Russell King <rmk@dyn-67.arm.linux.org.uk> |
[SERIAL] Remove wrong asm/serial.h inclusions asm/serial.h is supposed to contain the definitions for the architecture specific 8250 ports for the 8250 driver. It may also define BASE_BAUD, but this is the base baud for the architecture specific ports _only_. Therefore, nothing other than the 8250 driver should be including this header file. In order to move towards this goal, here is a patch which removes some of the more obvious incorrect includes of the file. Acked-by: Paul Fulghum <paulkf@microgate.com> Acked-by: Tony Luck <tony.luck@intel.com> Acked-by: Ralf Baechle <ralf@linux-mips.org> Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
/arch/ia64/kernel/setup.c
|
ae3e0218621db0590163b2d5c424ef1f340e3cc6 |
|
26-Sep-2006 |
Tony Luck <tony.luck@intel.com> |
Pull model-name into release branch
|
894673ee6122a3ce1958e1fe096901ba5356a96b |
|
10-Jul-2006 |
Jon Smirl <jonsmir@gmail.com> |
[PATCH] tty: Remove include of screen_info.h from tty.h screen_info.h doesn't have anything to do with the tty layer and shouldn't be included by tty.h. This patches removes the include and modifies all users to directly include screen_info.h. struct screen_info is mainly used to communicate with the console drivers in drivers/video/console. Note that this patch touches every arch and I have no way of testing it. If there is a mistake the worst thing that will happen is a compile error. [akpm@osdl.org: fix arm build] [akpm@osdl.org: fix alpha build] Signed-off-by: Jon Smirl <jonsmir@gmail.com> Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
/arch/ia64/kernel/setup.c
|
6ab3d5624e172c553004ecc862bfeac16d9d68b7 |
|
30-Jun-2006 |
Jörn Engel <joern@wohnheim.fh-wedel.de> |
Remove obsolete #include <linux/config.h> Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
/arch/ia64/kernel/setup.c
|
5eb1d63f5fc8455269c2756223b3cf3779fd2f7a |
|
06-Jun-2006 |
Alex Williamson <alex.williamson@hp.com> |
[IA64] sanity check reserved region usage One more trivial, stand-alone patch from the Xen/ia64 review. Sanity check usage of the reserved region numbers. Signed-off-by: Alex Williamson <alex.williamson@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
76d08bb3f09054edc45326ce5c698a3f6c45f5d0 |
|
05-Jun-2006 |
Tony Luck <tony.luck@intel.com> |
[IA64] Add "model name" to /proc/cpuinfo Linux ia64 port tried to decode the processor family number to something human-readable, but Intel brandnames don't change synchronously with updates to the family number. Adopt a more i386-like approach and just print the family number in decimal. Add a new field "model name" that uses PAL_BRAND_INFO to find the official name for the cpu, or on older systems, falls back to using the well-known codenames (Merced, McKinley, Madison). Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
b2c99e3c70d77fb194df5aa1642030080d28ea48 |
|
26-Mar-2006 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
[PATCH] EFI: keep physical table addresses in efi structure Almost all users of the table addresses from the EFI system table want physical addresses. So rather than doing the pa->va->pa conversion, just keep physical addresses in struct efi. This fixes a DMI bug: the efi structure contained the physical SMBIOS address on x86 but the virtual address on ia64, so dmi_scan_machine() used ioremap() on a virtual address on ia64. This is essentially the same as an earlier patch by Matt Tolentino: http://marc.theaimsgroup.com/?l=linux-kernel&m=112130292316281&w=2 except that this changes all table addresses, not just ACPI addresses. Matt's original patch was backed out because it caused MCAs on HP sx1000 systems. That problem is resolved by the ioremap() attribute checking added for ia64. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Matt Domsch <Matt_Domsch@dell.com> Cc: "Tolentino, Matthew E" <matthew.e.tolentino@intel.com> Cc: "Brown, Len" <len.brown@intel.com> Cc: Andi Kleen <ak@muc.de> Acked-by: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
/arch/ia64/kernel/setup.c
|
3ed3bce846abc7ef460104b461cac793e41afe5e |
|
26-Mar-2006 |
Matt Domsch <Matt_Domsch@dell.com> |
[PATCH] ia64: use i386 dmi_scan.c Enable DMI table parsing on ia64. Andi Kleen has a patch in his x86_64 tree which enables the use of i386 dmi_scan.c on x86_64. dmi_scan.c functions are being used by the drivers/char/ipmi/ipmi_si_intf.c driver for autodetecting the ports or memory spaces where the IPMI controllers may be found. This patch adds equivalent changes for ia64 as to what is in the x86_64 tree. In addition, I reworked the DMI detection, such that on EFI-capable systems, it uses the efi.smbios pointer to find the table, rather than brute-force searching from 0xF0000. On non-EFI systems, it continues the brute-force search. My test system, an Intel S870BN4 'Tiger4', aka Dell PowerEdge 7250, with latest BIOS, does not list the IPMI controller in the ACPI namespace, nor does it have an ACPI SPMI table. Also note, currently shipping Dell x8xx EM64T servers don't have these either, so DMI is the only method for obtaining the address of the IPMI controller. Signed-off-by: Matt Domsch <Matt_Domsch@dell.com> Acked-by: "Luck, Tony" <tony.luck@intel.com> Cc: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
/arch/ia64/kernel/setup.c
|
7d14f145f839b5d0d221ea209b4998f93267e2ec |
|
25-Mar-2006 |
Linus Torvalds <torvalds@g5.osdl.org> |
Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6 * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6: [IA64] New IA64 core/thread detection patch [IA64] Increase max node count on SN platforms [IA64] Increase max node count on SN platforms [IA64] Increase max node count on SN platforms [IA64] Increase max node count on SN platforms [IA64] Tollhouse HP: IA64 arch changes [IA64] cleanup dig_irq_init [IA64] MCA recovery: kernel context recovery table IA64: Use early_parm to handle mvec_name and nomca [IA64] move patchlist and machvec into init section [IA64] add init declaration - nolwsys [IA64] add init declaration - gate page functions [IA64] add init declaration to memory initialization functions [IA64] add init declaration to cpu initialization functions [IA64] add __init declaration to mca functions [IA64] Ignore disabled Local SAPIC Affinity Structure in SRAT [IA64] sn_check_intr: use ia64_get_irr() [IA64] fix ia64 is_hugepage_only_range
|
cdb0452789d365695b5b173542af9c7e3d24f185 |
|
24-Mar-2006 |
Adrian Bunk <bunk@stusta.de> |
[PATCH] kill include/linux/platform.h, default_idle() cleanup include/linux/platform.h contained nothing that was actually used except the default_idle() prototype, and is therefore removed by this patch. This patch does the following with the platform specific default_idle() functions on different architectures: - remove the unused function: - parisc - sparc64 - make the needlessly global function static: - arm - h8300 - m68k - m68knommu - s390 - v850 - x86_64 - add a prototype in asm/system.h: - cris - i386 - ia64 Signed-off-by: Adrian Bunk <bunk@stusta.de> Acked-by: Patrick Mochel <mochel@digitalimplant.org> Acked-by: Kyle McMartin <kyle@parisc-linux.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
/arch/ia64/kernel/setup.c
|
a5b00bb4fe60796c791238cf5653b82110031c93 |
|
23-Mar-2006 |
Horms <horms@verge.net.au> |
IA64: Use early_parm to handle mvec_name and nomca I'm not sure of the worthiness of this idea, so please consider it an RFC. Its key merits are: * Reuse existing infrastructure * Greatly tightens up the parsing of nomca * Greatly simplifies the parsing of machvec Addition cleanup (moving setup_mvec() to machvec.c) by Ken Chen. Signed-Off-By: Horms <horms@verge.net.au> Signed-Off-By: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
dae2806615c91cd7afa7c4dee65518435e45854a |
|
23-Mar-2006 |
Chen, Kenneth W <kenneth.w.chen@intel.com> |
[IA64] add init declaration to memory initialization functions Add init declaration to variables/functions used for memory initialization. I don't think they would clash with memory hotplug. If they do, please yell. Signed-off-by: Ken Chen <kenneth.w.chen@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
244fd54540806a5e3391d117794105a35815cbb2 |
|
12-Mar-2006 |
Chen, Kenneth W <kenneth.w.chen@intel.com> |
[IA64] add init declaration to cpu initialization functions Add init declaration to cpu initialization functions. Signed-off-by: Ken Chen <kenneth.w.chen@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
a6b14fa6fdc01ab3519c2729624f808677539b59 |
|
15-Feb-2006 |
Ashok Raj <ashok.raj@intel.com> |
[IA64] Count disabled cpus as potential hot-pluggable CPUs Have a facility to account for potentially hot-pluggable CPUs. ACPI doesnt give a determinstic method to find hot-pluggable CPUs. Hence we use 2 methods to assist. - BIOS can mark potentially hot-pluggable CPUs as disabled in the MADT tables. - User can specify the number of hot-pluggable CPUs via parameter additional_cpus=X The option is enabled only if ACPI_CONFIG_HOTPLUG_CPU=y which enables the physical hotplug option. Without which user can still use logical onlining and offlining of CPUs by enabling CONFIG_HOTPLUG_CPU=y Adds more bits to cpu_possible_map for potentially hot-pluggable cpus. Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
d6e56a2a088935f3c1feee5ff5a06c67f2ec6002 |
|
08-Feb-2006 |
Tony Luck <tony.luck@intel.com> |
[IA64] Fix CONFIG_PRINTK_TIME There were two problems with enabling the PRINTK_TIME config option: 1) The first calls to printk() occur before per-cpu data virtual address is pinned into the TLB, so sched_clock() can fault. 2) sched_clock() is based on ar.itc, which may not be synchronized across cpus. Ken Chen started this patch, Tony Luck tinkered with it, and Jes Sorensen perfected it. Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
6450578f32cdca587ae5f148e2118b2fcc36bb11 |
|
12-Jan-2006 |
Al Viro <viro@ftp.linux.org.uk> |
[PATCH] ia64: task_pt_regs() Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
/arch/ia64/kernel/setup.c
|
198e2f181163233b379dc7ce8a6d7516b84042e7 |
|
12-Jan-2006 |
akpm@osdl.org <akpm@osdl.org> |
[PATCH] scheduler cache-hot-autodetect From: Ingo Molnar <mingo@elte.hu> This is the latest version of the scheduler cache-hot-auto-tune patch. The first problem was that detection time scaled with O(N^2), which is unacceptable on larger SMP and NUMA systems. To solve this: - I've added a 'domain distance' function, which is used to cache measurement results. Each distance is only measured once. This means that e.g. on NUMA distances of 0, 1 and 2 might be measured, on HT distances 0 and 1, and on SMP distance 0 is measured. The code walks the domain tree to determine the distance, so it automatically follows whatever hierarchy an architecture sets up. This cuts down on the boot time significantly and removes the O(N^2) limit. The only assumption is that migration costs can be expressed as a function of domain distance - this covers the overwhelming majority of existing systems, and is a good guess even for more assymetric systems. [ People hacking systems that have assymetries that break this assumption (e.g. different CPU speeds) should experiment a bit with the cpu_distance() function. Adding a ->migration_distance factor to the domain structure would be one possible solution - but lets first see the problem systems, if they exist at all. Lets not overdesign. ] Another problem was that only a single cache-size was used for measuring the cost of migration, and most architectures didnt set that variable up. Furthermore, a single cache-size does not fit NUMA hierarchies with L3 caches and does not fit HT setups, where different CPUs will often have different 'effective cache sizes'. To solve this problem: - Instead of relying on a single cache-size provided by the platform and sticking to it, the code now auto-detects the 'effective migration cost' between two measured CPUs, via iterating through a wide range of cachesizes. The code searches for the maximum migration cost, which occurs when the working set of the test-workload falls just below the 'effective cache size'. I.e. real-life optimized search is done for the maximum migration cost, between two real CPUs. This, amongst other things, has the positive effect hat if e.g. two CPUs share a L2/L3 cache, a different (and accurate) migration cost will be found than between two CPUs on the same system that dont share any caches. (The reliable measurement of migration costs is tricky - see the source for details.) Furthermore i've added various boot-time options to override/tune migration behavior. Firstly, there's a blanket override for autodetection: migration_cost=1000,2000,3000 will override the depth 0/1/2 values with 1msec/2msec/3msec values. Secondly, there's a global factor that can be used to increase (or decrease) the autodetected values: migration_factor=120 will increase the autodetected values by 20%. This option is useful to tune things in a workload-dependent way - e.g. if a workload is cache-insensitive then CPU utilization can be maximized by specifying migration_factor=0. I've tested the autodetection code quite extensively on x86, on 3 P3/Xeon/2MB, and the autodetected values look pretty good: Dual Celeron (128K L2 cache): --------------------- migration cost matrix (max_cache_size: 131072, cpu: 467 MHz): --------------------- [00] [01] [00]: - 1.7(1) [01]: 1.7(1) - --------------------- cacheflush times [2]: 0.0 (0) 1.7 (1784008) --------------------- Here the slow memory subsystem dominates system performance, and even though caches are small, the migration cost is 1.7 msecs. Dual HT P4 (512K L2 cache): --------------------- migration cost matrix (max_cache_size: 524288, cpu: 2379 MHz): --------------------- [00] [01] [02] [03] [00]: - 0.4(1) 0.0(0) 0.4(1) [01]: 0.4(1) - 0.4(1) 0.0(0) [02]: 0.0(0) 0.4(1) - 0.4(1) [03]: 0.4(1) 0.0(0) 0.4(1) - --------------------- cacheflush times [2]: 0.0 (33900) 0.4 (448514) --------------------- Here it can be seen that there is no migration cost between two HT siblings (CPU#0/2 and CPU#1/3 are separate physical CPUs). A fast memory system makes inter-physical-CPU migration pretty cheap: 0.4 msecs. 8-way P3/Xeon [2MB L2 cache]: --------------------- migration cost matrix (max_cache_size: 2097152, cpu: 700 MHz): --------------------- [00] [01] [02] [03] [04] [05] [06] [07] [00]: - 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) [01]: 19.2(1) - 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) [02]: 19.2(1) 19.2(1) - 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) [03]: 19.2(1) 19.2(1) 19.2(1) - 19.2(1) 19.2(1) 19.2(1) 19.2(1) [04]: 19.2(1) 19.2(1) 19.2(1) 19.2(1) - 19.2(1) 19.2(1) 19.2(1) [05]: 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) - 19.2(1) 19.2(1) [06]: 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) - 19.2(1) [07]: 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) - --------------------- cacheflush times [2]: 0.0 (0) 19.2 (19281756) --------------------- This one has huge caches and a relatively slow memory subsystem - so the migration cost is 19 msecs. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Ken Chen <kenneth.w.chen@intel.com> Cc: <wilder@us.ibm.com> Signed-off-by: John Hawkes <hawkes@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
/)
/arch/ia64/kernel/setup.c
|
4dc7a0bbeb6882ad665e588e82fabe5bb4645f2f |
|
12-Jan-2006 |
Ingo Molnar <mingo@elte.hu> |
[PATCH] sched: add cacheflush() asm Add per-arch sched_cacheflush() which is a write-back cacheflush used by the migration-cost calibration code at bootup time. Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
/arch/ia64/kernel/setup.c
|
38c0b2c2aaab5595a140ade4410e01d407fff751 |
|
05-Jan-2006 |
Tony Luck <tony.luck@intel.com> |
[IA64] Fix compile warnings in setup.c arch/ia64/kernel/setup.c: In function `show_cpuinfo': arch/ia64/kernel/setup.c:576: warning: long unsigned int format, different type arg (arg 12) arch/ia64/kernel/setup.c:576: warning: long unsigned int format, different type arg (arg 13) Introduced by 95235ca2c20ac0b31a8eb39e2d599bcc3e9c9a10 Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
95235ca2c20ac0b31a8eb39e2d599bcc3e9c9a10 |
|
02-Dec-2005 |
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> |
[CPUFREQ] CPU frequency display in /proc/cpuinfo What is the value shown in "cpu MHz" of /proc/cpuinfo when CPUs are capable of changing frequency? Today the answer is: It depends. On i386: SMP kernel - It is always the boot frequency UP kernel - Scales with the frequency change and shows that was last set. On x86_64: There is one single variable cpu_khz that gets written by all the CPUs. So, the frequency set by last CPU will be seen on /proc/cpuinfo of all the CPUs in the system. What you see also depends on whether you have constant_tsc capable CPU or not. On ia64: It is always boot time frequency of a particular CPU that gets displayed. The patch below changes this to: Show the last known frequency of the particular CPU, when cpufreq is present. If cpu doesnot support changing of frequency through cpufreq, then boot frequency will be shown. The patch affects i386, x86_64 and ia64 architectures. Signed-off-by: Venkatesh Pallipadi<venkatesh.pallipadi@intel.com> Signed-off-by: Dave Jones <davej@redhat.com>
/arch/ia64/kernel/setup.c
|
7669a22592fc6cc7ac03f55a7db8d23ce938f1dc |
|
10-Nov-2005 |
Tony Luck <tony.luck@intel.com> |
Pull context-bitmap into release branch
|
e1531b4218a7ccfc1b2234b87105201e5ebe1bbf |
|
07-Nov-2005 |
John W. Linville <linville@tuxdriver.com> |
[PATCH] ia64: re-implement dma_get_cache_alignment to avoid EXPORT_SYMBOL The current ia64 implementation of dma_get_cache_alignment does not work for modules because it relies on a symbol which is not exported. Direct access to a global is a little ugly anyway, so this patch re-implements dma_get_cache_alignment in a manner similar to what is currently used for x86_64. Signed-off-by: John W. Linville <linville@tuxdriver.com> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
/arch/ia64/kernel/setup.c
|
dcc17d1baef3721d1574e5b2f4f2d4607514bcff |
|
31-Oct-2005 |
Peter Keilty <peter.keilty@hp.com> |
[IA64] Use bitmaps for efficient context allocation/free Corrects the very inefficent method of finding free context_ids in get_mmu_context(). Instead of walking the task_list of all processes, 2 bitmaps are used to efficently store and lookup state, inuse and needs flushing. The entire rid address space is now used before calling wrap_mmu_context and global tlb flushing. Special thanks to Ken and Rohit for their review and modifications in using a bit flushmap. Signed-off-by: Peter Keilty <peter.keilty@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
5a2b1722e1051b84485a77006abe9b929aedef32 |
|
28-Oct-2005 |
Tony Luck <tony.luck@intel.com> |
Pull proc-cpuinfo-siblings into release branch
|
5833f1420b96c4f9b193b7f2fcbc0003dc032fe8 |
|
28-Oct-2005 |
Tony Luck <tony.luck@intel.com> |
Pull new-efi-memmap into release branch
|
ce6e71ad4866dad366be135b024b776c00ec9ec8 |
|
05-Oct-2005 |
Siddha, Suresh B <suresh.b.siddha@intel.com> |
[IA64] fix siblings field value in /proc/cpuinfo Fix the "siblings" field value in /proc/cpuinfo so that it now shows the number of siblings as seen by OS, instead of what is available from hardware perspective. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
d719948e623622cf9fc8016f7ec63422d929eb3b |
|
29-Sep-2005 |
Tony Luck <tony.luck@intel.com> |
[IA64] end of kernel 'data' is at _end, not _edata /proc/iomem describes a block of memory as "Kernel data", but the end address is derived from "_edata". The kernel actually has many other sections beyond _edata. Get the real end address from _end. Acked-by: Khalid Aziz <khalid_aziz@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
44c451208da397438e7062393aeb3a19ddb76a60 |
|
16-Sep-2005 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
[IA64] ia64: add ar.k0 usage note Update comment about how ar.k0 is used. Make the initialization the same as in start_secondary() (no functional change, just make it look more similar). Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
be379124c0a5abfbe57dab2823fe8a71ce797aee |
|
20-Sep-2005 |
Khalid Aziz <khalid.aziz@hp.com> |
[IA64] include EFI memory information in /proc/iomem User mode kexec tools expect to find information about physical memory in /proc/iomem (as they do on x86) to validate the addresses that the new kernel will use. Signed-off-by: Khalid Aziz <khalid.aziz@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
d8c97d5f3aa348272df2ccb4e224b1cf9a1eb6d7 |
|
08-Sep-2005 |
Tony Luck <tony.luck@intel.com> |
[IA64] simplified efi memory map parsing New version leaves the original memory map unmodified. Also saves any granule trimmings for use by the uncached memory allocator. Inspired by Khalid Aziz (various traces of his patch still remain). Fixes to uncached_build_memmap() and sn2 testing by Martin Hicks. Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
888ba6c62bc61a995d283977eb3a6cbafd6f4ac6 |
|
24-Aug-2005 |
Len Brown <len.brown@intel.com> |
[ACPI] delete CONFIG_ACPI_BOOT it has been a synonym for CONFIG_ACPI since 2.6.12 Signed-off-by: Len Brown <len.brown@intel.com>
/arch/ia64/kernel/setup.c
|
99ad25a313bda566a346b46a6015afa65bc0a02b |
|
13-Jul-2005 |
Tony Luck <tony.luck@intel.com> |
Auto merge with /home/aegl/GIT/linus
|
08357f82d4decc48bbfd39ae30d5fe0754f7f576 |
|
03-Jun-2005 |
Zoltan Menyhart <Zoltan.Menyhart@bull.net> |
[IA64] improve flush_icache_range() Check with PAL to see what the i-cache line size is for each level of the cache, and so use the correct stride when flushing the cache. Acked-by: David Mosberger Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
5028770a42e7bc4d15791a44c28f0ad539323807 |
|
12-Jul-2005 |
Len Brown <len.brown@intel.com> |
[ACPI] merge acpi-2.6.12 branch into latest Linux 2.6.13-rc... Signed-off-by: Len Brown <len.brown@intel.com>
|
6c4fa56033c11ad5c5929bf3edd1505d3d8a8c0b |
|
19-Apr-2005 |
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> |
[ACPI] fix C1 patch for IA64 http://bugzilla.kernel.org/show_bug.cgi?id=4233 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
/arch/ia64/kernel/setup.c
|
66b7f8a30437b8639e798f7db8e9be1da5711efa |
|
25-Apr-2005 |
Mark Maule <maule@sgi.com> |
[IA64-SGI] pcdp: add PCDP pci interface support Resend 2 with changes per Bjorn Helgaas comments. Changes from original: + Change globals to vga_console_iobase/vga_console_membase and make them unconditional. + Address style-related comments. Patch to extend the PCDP vga setup code to support PCI io/mem translations for the legacy vga ioport and ram spaces on architectures (e.g. altix) which need them. Summary of the changes: drivers/firmware/pcdp.c drivers/firmware/pcdp.h ----------------------- + add declaration for the spec-defined PCI interface struct (pcdp_if_pci) as well as support macros. + extend setup_vga_console() to know about pcdp_if_pci and add a couple of globals to hold the io and mem translation offsets if present. arch/ia64/kernel/setup.c ------------------------ + tweek early_console_setup() to allow multiple early console setup routines to be called. include/asm-ia64/vga.h ---------------------- + make VGA_MAP_MEM vga_console_membase aware Signed-off-by: Mark Maule <maule@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
86ebacd360767f6a5cf9c8810977593dccf3f3da |
|
08-Jun-2005 |
Tony Luck <tony.luck@intel.com> |
[IA64] Update comment to describe modes set in default control register. Christian Hildner pointed out that the comment did not match what the code does in cpu_init() when we set up the default control register. Patch based on suggestions from Ken Chen. Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
e1ed81ab7a34fc0f92f2e200825bdb6d86d6c8ef |
|
25-Apr-2005 |
Tony Luck <tony.luck@intel.com> |
[IA64] print "siblings" before {physical,core,thread} id Rohit and Suresh changed their mind about the order to print things in /proc/cpuinfo, but didn't include the change in the version of the patch they sent to me. Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
e927ecb05e1ce4bbb1e10f57008c94994e2160f5 |
|
25-Apr-2005 |
Suresh Siddha <suresh.b.siddha@intel.com> |
[IA64] multi-core/multi-thread identification Version 3 - rediffed to apply on top of Ashok's hotplug cpu patch. /proc/cpuinfo output in step with x86. This is an updated MC/MT identification patch based on the previous discussions on list. Add the Multi-core and Multi-threading detection for IPF. - Add new core and threading related fields in /proc/cpuinfo. Physical id Core id Thread id Siblings - setup the cpu_core_map and cpu_sibling_map appropriately - Handles Hot plug CPU Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Gordon Jin <gordon.jin@intel.com> Signed-off-by: Rohit Seth <rohit.seth@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
/arch/ia64/kernel/setup.c
|
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 |
|
17-Apr-2005 |
Linus Torvalds <torvalds@ppc970.osdl.org> |
Linux-2.6.12-rc2 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!
/arch/ia64/kernel/setup.c
|