aboutsummaryrefslogtreecommitdiff
path: root/arch/ia64/kernel/head.S
AgeCommit message (Collapse)Author
2009-10-29percpu: make percpu symbols in ia64 uniqueTejun Heo
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
2009-09-25[IA64] implement ticket locks for ItaniumTony Luck
Back in January 2008 Nick Piggin implemented "ticket" spinlocks for X86 (See commit 314cdbefd1fd0a7acf3780e9628465b77ea6a836). IA64 implementation has a couple of differences because of the available atomic operations ... e.g. we have no fetchadd2 instruction that operates on a 16-bit quantity so we make ticket locks use a 32-bit word for each of the current ticket and now-serving values. Performance on uncontended locks is about 8% worse than the previous implementation, but this seems a good trade for determinism in the contended case. Performance impact on macro-level benchmarks is in the noise. Signed-off-by: Tony Luck <tony.luck@intel.com>
2009-09-15[IA64] Use standard macros for page-aligned data.Nelson Elhage
Signed-off-by: Nelson Elhage <nelhage@ksplice.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2009-09-15[IA64] Use .ref.text, not .text.init for start_ap.Tim Abbott
It seems that start_ap doesn't need to be in a special location in the kernel, but it references some init code so it should be in .ref.text. Since this is the only thing in the .text.head section, eliminate .text.head from the linker script. Signed-off-by: Tim Abbott <tabbott@ksplice.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2009-09-14[IA64] kdump: Mask MCA/INIT on frozen cpusHidetoshi Seto
Summary: INIT asserted on kdump kernel invokes INIT handler not only on a cpu that running on the kdump kernel, but also BSP of the panicked kernel, because the (badly) frozen BSP can be thawed by INIT. Description: The kdump_cpu_freeze() is called on cpus except one that initiates panic and/or kdump, to stop/offline the cpu (on ia64, it means we pass control of cpus to SAL, or put them in spinloop). Note that CPU0(BSP) always go to spinloop, so if panic was happened on an AP, there are at least 2cpus (= the AP and BSP) which not back to SAL. On the spinning cpus, interrupts are disabled (rsm psr.i), but INIT is still interruptible because psr.mc for mask them is not set unless kdump_cpu_freeze() is not called from MCA/INIT context. Therefore, assume that a panic was happened on an AP, kdump was invoked, new INIT handlers for kdump kernel was registered and then an INIT is asserted. From the viewpoint of SAL, there are 2 online cpus, so INIT will be delivered to both of them. It likely means that not only the AP (= a cpu executing kdump) enters INIT handler which is newly registered, but also BSP (= another cpu spinning in panicked kernel) enters the same INIT handler. Of course setting of registers in BSP are still old (for panicked kernel), so what happen with running handler with wrong setting will be extremely unexpected. I believe this is not desirable behavior. How to Reproduce: Start kdump on one of APs (e.g. cpu1) # taskset 0x2 echo c > /proc/sysrq-trigger Then assert INIT after kdump kernel is booted, after new INIT handler for kdump kernel is registered. Expected results: An INIT handler is invoked only on the AP. Actual results: An INIT handler is invoked on the AP and BSP. Sample of results: I got following console log by asserting INIT after prompt "root:/>". It seems that two monarchs appeared by one INIT, and one panicked at last. And it also seems that the panicked one supposed there were 4 online cpus and no one did rendezvous: : [ 0 %]dropping to initramfs shell exiting this shell will reboot your system root:/> Entered OS INIT handler. PSP=fff301a0 cpu=0 monarch=0 ia64_init_handler: Promoting cpu 0 to monarch. Delaying for 5 seconds... All OS INIT slaves have reached rendezvous Processes interrupted by INIT - 0 (cpu 0 task 0xa000000100af0000) : <<snip>> : Entered OS INIT handler. PSP=fff301a0 cpu=0 monarch=1 Delaying for 5 seconds... mlogbuf_finish: printing switched to urgent mode, MCA/INIT might be dodgy or fail. OS INIT slave did not rendezvous on cpu 1 2 3 INIT swapper 0[0]: bugcheck! 0 [1] : <<snip>> : Kernel panic - not syncing: Attempted to kill the idle task! Proposed fix: To avoid this problem, this patch inserts ia64_set_psr_mc() to mask INIT on cpus going to be frozen. This masking have no effect if the kdump_cpu_freeze() is called from INIT handler when kdump_on_init == 1, because psr.mc is already turned on to 1 before entering OS_INIT. I confirmed that weird log like above are disappeared after applying this patch. Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Haren Myneni <hbabu@us.ibm.com> Cc: kexec@lists.infradead.org Acked-by: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2009-03-26ia64/pv_ops/pv_time_ops: add sched_clock hook.Isaku Yamahata
add sched_clock() hook to paravirtualize sched_clock(). ia64 sched_clock() is based on ar.itc which isn't stable on virtualized environment because vcpu may move around on pcpus. So it needs paravirtualization. Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp> Signed-off-by: Tony Luck <tony.luck@intel.com>
2008-11-20[IA64] Rationalize kernel mode alignment checkingTony Luck
Itanium processors can handle some misaligned data accesses. They also provide a mode where all such accesses are forced to trap. The kernel was schizophrenic about use of this mode: * Base kernel code ran in permissive mode where the only traps generated were from those cases that the h/w could not handle. * Interrupt, syscall and trap code ran in strict mode where all unaligned accesses caused traps to the 0x5a00 unaligned reference vector. Use strict alignment checking throughout the kernel, but make sure that we continue to let user mode use more relaxed mode as the default. Signed-off-by: Tony Luck <tony.luck@intel.com>
2008-09-29[IA64] Put the space for cpu0 per-cpu area into .data sectionTony Luck
Initial fix for making sure that we can access percpu variables in all C code (commit: 10617bbe84628eb18ab5f723d3ba35005adde143) inadvertantly allocated the memory in the "percpu" section of the vmlinux ELF executable. This confused kexec/dump. Signed-off-by: Tony Luck <tony.luck@intel.com>
2008-08-12[IA64] Ensure cpu0 can access per-cpu variables in early boot codeTony Luck
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>
2008-08-01[IA64] Move include/asm-ia64 to arch/ia64/include/asmTony Luck
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>
2008-05-27[IA64] pvops: add an early setup hook for pv_ops.Isaku Yamahata
This patch adds a setup hook in the very early boot sequence before start_kernel() to initialize paravirtualization stuff. The hook will be set by each pv loader code or by using multi entry point. Signed-off-by: Qing He <qing.he@intel.com> Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp> Signed-off-by: Tony Luck <tony.luck@intel.com>
2008-02-20[IA64] VIRT_CPU_ACCOUNTING (accurate cpu time accounting)Hidetoshi Seto
This patch implements VIRT_CPU_ACCOUNTING for ia64, which enable us to use more accurate cpu time accounting. The VIRT_CPU_ACCOUNTING is an item of kernel config, which s390 and powerpc arch have. By turning this config on, these archs change the mechanism of cpu time accounting from tick-sampling based one to state-transition based one. The state-transition based accounting is done by checking time (cycle counter in processor) at every state-transition point, such as entrance/exit of kernel, interrupt, softirq etc. The difference between point to point is the actual time consumed during in the state. There is no doubt about that this value is more accurate than that of tick-sampling based accounting. Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2007-12-19[IA64] Remove assembler warnings on head.SHidetoshi Seto
This patch removes the following assembler warning messages. AS arch/ia64/kernel/head.o arch/ia64/kernel/head.S: Assembler messages: arch/ia64/kernel/head.S:1179: Warning: Use of 'ld8' violates RAW dependency 'CR[PTA]' (data) arch/ia64/kernel/head.S:1179: Warning: Only the first path encountering the conflict is reported arch/ia64/kernel/head.S:1178: Warning: This is the location of the conflicting usage arch/ia64/kernel/head.S:1180: Warning: Use of 'ld8' violates RAW dependency 'CR[PTA]' (data) arch/ia64/kernel/head.S:1180: Warning: Only the first path encountering the conflict is reported arch/ia64/kernel/head.S:1178: Warning: This is the location of the conflicting usage : arch/ia64/kernel/head.S:1213: Warning: Use of 'ldf.fill.nta' violates RAW dependency 'CR[PTA]' (data) arch/ia64/kernel/head.S:1213: Warning: Only the first path encountering the conflict is reported arch/ia64/kernel/head.S:1178: Warning: This is the location of the conflicting usage Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2007-07-25[IA64] fix section mismatch warningsTony Luck
In 741f98fe298a73c9d47ed53703c1279a29718581 Sam added full checking across the entire vmlinux image. This flushed out a dozen new section mismatch warnings. Start the whack-a-mole game again to stomp them out. Signed-off-by: Tony Luck <tony.luck@intel.com>
2006-09-08[IA64] Save register stack contents on cpu startJack Steiner
The SN PROM uses the register stack in the slave loop. The contents must be preserved for the OS to return to the slave loop via offlining a cpu or for kexec. A 'flushrs" is needed to force the stack to be written to memory prior to changing bspstore. Signed-off-by: Jack Steiner <steiner@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2006-08-02[IA64] Don't alloc empty frame in ia64_switch_mode_physZou Nan hai
I think ia64_switch_mode_phys and ia64_switch_mode_virt does not need to alloc an empty frame. An empty frame is required by loadrs but flushrs does not need that. Signed-off-by: Zou Nan hai <nanhai.zou@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2006-06-30Remove obsolete #include <linux/config.h>Jörn Engel
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-02-07[IA64] Fix CONFIG_PRINTK_TIMETony Luck
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>
2006-01-08[PATCH] remove gcc-2 checksAndrew Morton
Remove various things which were checking for gcc-1.x and gcc-2.x compilers. From: Adrian Bunk <bunk@stusta.de> Some documentation updates and removes some code paths for gcc < 3.2. Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09kbuild: ia64 use generic asm-offsets.h supportSam Ravnborg
Delete obsolete stuff from arch Makefile Rename file to asm-offsets.h The trick used in the arch Makefile to circumvent the circular dependency is kept. Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2005-04-22[IA64] Fix build errors for !HOTPLUG case.Ashok Raj
Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2005-04-22[IA64] cpu hotplug: return offlined cpus to SALAshok Raj
This patch is required to support cpu removal for IPF systems. Existing code just fakes the real offline by keeping it run the idle thread, and polling for the bit to re-appear in the cpu_state to get out of the idle loop. For the cpu-offline to work correctly, we need to pass control of this CPU back to SAL so it can continue in the boot-rendez mode. This gives the SAL control to not pick this cpu as the monarch processor for global MCA events, and addition does not wait for this cpu to checkin with SAL for global MCA events as well. The handoff is implemented as documented in SAL specification section 3.2.5.1 "OS_BOOT_RENDEZ to SAL return State" Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!