kernel.git/arch/ia64/kernel/mca_asm.S, branch linux-2.6.28.y

[IA64] Add API for allocating Dynamic TR resource.

2008-04-03T18:02:58Z

Dynamic TR resource should be managed in the uniform way. Add two interfaces for kernel: ia64_itr_entry: Allocate a (pair of) TR for caller. ia64_ptr_entry: Purge a (pair of ) TR by caller. Signed-off-by: Xiantao Zhang Signed-off-by: Anthony Xu Signed-off-by: Tony Luck

[IA64] mca style cleanup

2008-02-04T23:42:06Z

Unified changelog, 80 columns rule, and address form fix. Signed-off-by: Hidetoshi Seto Signed-off-by: Tony Luck

[IA64] Support multiple CPUs going through OS_MCA

2007-07-11T18:50:11Z

Linux does not gracefully deal with multiple processors going through OS_MCA aa part of the same MCA event. The first cpu into OS_MCA grabs the ia64_mca_serialize lock. Subsequent cpus wait for that lock, preventing them from reporting in as rendezvoused. The first cpu waits 5 seconds then complains that all the cpus have not rendezvoused. The first cpu then handles its MCA and frees up all the rendezvoused cpus and releases the ia64_mca_serialize lock. One of the subsequent cpus going thought OS_MCA then gets the ia64_mca_serialize lock, waits another 5 seconds and then complains that none of the other cpus have rendezvoused. This patch allows multiple CPUs to gracefully go through OS_MCA. The first CPU into ia64_mca_handler() grabs a mca_count lock. Subsequent CPUs into ia64_mca_handler() are added to a list of cpus that need to go through OS_MCA (a bit set in mca_cpu), and report in as rendezvoused, and but spin waiting their turn. The first CPU sees everyone rendezvous, handles his MCA, wakes up one of the other CPUs waiting to process their MCA (by clearing one mca_cpu bit), and then waits for the other cpus to complete their MCA handling. The next CPU handles his MCA and the process repeats until all the CPUs have handled their MCA. When the last CPU has handled it's MCA, it sets monarch_cpu to -1, releasing all the CPUs. In testing this works more reliably and faster. Thanks to Keith Owens for suggesting numerous improvements to this code. Signed-off-by: Russ Anderson Signed-off-by: Tony Luck

[IA64] relax per-cpu TLB requirement to DTC

2007-02-06T23:04:48Z

Instead of pinning per-cpu TLB into a DTR, use DTC. This will free up one TLB entry for application, or even kernel if access pattern to per-cpu data area has high temporal locality. Since per-cpu is mapped at the top of region 7 address, we just need to add special case in alt_dtlb_miss. The physical address of per-cpu data is already conveniently stored in IA64_KR(PER_CPU_DATA). Latency for alt_dtlb_miss is not affected as we can hide all the latency. It was measured that alt_dtlb_miss handler has 23 cycles latency before and after the patch. The performance effect is massive for applications that put lots of tlb pressure on CPU. Workload environment like database online transaction processing or application uses tera-byte of memory would benefit the most. Measurement with industry standard database benchmark shown an upward of 1.6% gain. While smaller workloads like cpu, java also showing small improvement. Signed-off-by: Ken Chen Signed-off-by: Tony Luck

[IA64] ar.fpsr not set on MCA/INIT kernel entry

2006-09-26T22:20:35Z

When entering the kernel due to an MCA or INIT, ar.fpsr (ar40) was not getting set to the kernel default value (remaining at the user value). The effect depends on the user setting of ar.fpsr. In the test case, the effect was addresses printing with strange hex values. Setting ar.fpsr in ia64_set_kernel_registers sets it for both the MCA and INIT paths. The user value of ar.fpsr is correctly saved (in ia64_state_save) and restored (in ia64_state_restore). Below is an example of output with very strange hex values. Anyone know the value of hex 'g'? :-) Processes interrupted by INIT - 0 (cpu 14 task 0xdfffg55g7a4c6gA) Signed-off-by: Russ Anderson (rja@sgi.com) Signed-off-by: Tony Luck

[IA64] Make gp value point to Region 5 in mca handler

2006-09-26T21:13:03Z

MCA dispatch code take physical address of GP passed from SAL, then call DATA_PA_TO_VA twice on GP before call into C code. The first time is in ia64_set_kernel_register, the second time is in VIRTUAL_MODE_ENTER. The gp is changed to a virtual address in region 7 because DATA_PA_TO_VA is implemented by dep instruction. However when notify blocks were called from MCA handler code, because notify blocks are supported by callback function pointers, gp value value was switched to region 5 again. The patch set gp register to kernel gp of region 5 at entry of MCA dispatch. Signed-off-by: Zou Nan hai Signed-off-by: Tony Luck

Remove obsolete #include

2006-06-30T17:25:36Z

Signed-off-by: Jörn Engel Signed-off-by: Adrian Bunk

[IA64] Sanitize assembler code for ia64_sal_os_state

2006-06-21T21:44:26Z

struct ia64_sal_os_state has three semi-independent sections. The code in mca_asm.S assumes that these three sections are contiguous, which makes it very awkward to add new data to this structure. Remove the assumption that the sections are contiguous. Define a macro to shorten references to offsets in ia64_sal_os_state. This patch does not change the way that the code behaves. It just makes it easier to update the code in future and to add fields to ia64_sal_os_state when debugging the MCA/INIT handlers. Signed-off-by: Keith Owens Signed-off-by: Tony Luck

[IA64] Failure to resume after INIT in user space

2006-04-08T06:01:32Z

The OS INIT handler is loading incorrect values into cr.ifa on exit. This shows up as a hang when resuming after an INIT that is delivered while a cpu is in user space. Correct the value loaded into cr.ifa. Signed-off-by: Keith Owens Signed-off-by: Tony Luck

[IA64] Set the correct default OS status in the MCA handler

2006-01-24T19:50:07Z

sos->os_status is set to a default value of IA64_MCA_COLD_BOOT for an MCA, but then is incorrectly overwritten with IA64_MCA_SAME_CONTEXT (0). This makes SAL think that all MCAs have been recovered. Signed-off-by: Keith Owens Signed-off-by: Tony Luck