aboutsummaryrefslogtreecommitdiff
path: root/arch/m68k/fpsp040/srem_mod.S
diff options
context:
space:
mode:
authorAlex Chiang <achiang@hp.com>2008-06-11 17:29:27 -0600
committerTony Luck <tony.luck@intel.com>2008-06-11 16:40:33 -0700
commit3463a93def55c309f3c0d0a8aaf216be3be42d64 (patch)
tree50ce1913088287a7c8144e8db5fd3e7dc43842d1 /arch/m68k/fpsp040/srem_mod.S
parent83014699b06fb9a300d896c7c49fb8be1c6c5ddc (diff)
[IA64] Update check_sal_cache_flush to use platform_send_ipi()
check_sal_cache_flush is used to detect broken firmware that drops pending interrupts. The old implementation schedules a timer interrupt for itself in the future by getting the current value of the Interval Timer Counter + 1000 cycles, waits for the interrupt to be pended, calls SAL_CACHE_FLUSH, and finally checks to see if the interrupt is still pending. This implementation can cause problems for virtual machine code if the process of scheduling the timer interrupt takes more than 1000 cycles; the virtual machine can end up sleeping for several hundred years while waiting for the ITC to wrap around. The fix is to use platform_send_ipi. The processor will still send an interrupt to itself, using the IA64_IPI_DM_INT delivery mode, which causes the IPI to look like an external interrupt. The rest of the SAL_CACHE_FLUSH + checking to see if the interrupt is still pending remains unchanged. This fix has been boot tested successfully on: - intel tiger2 - hp rx6600 - hp rx5670 The rx5670 has known buggy firmware, where SAL_CACHE_FLUSH drops pending interrupts. A boot test on this machine showed this message on the console: SAL: SAL_CACHE_FLUSH drops interrupts; PAL_CACHE_FLUSH will be used instead Which proves that the self-inflicted IPI approach is viable. And as expected, the other tested platforms correctly did not display the warning. Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
Diffstat (limited to 'arch/m68k/fpsp040/srem_mod.S')
0 files changed, 0 insertions, 0 deletions