summaryrefslogtreecommitdiffstats
path: root/arch/m32r
diff options
context:
space:
mode:
authorHidetoshi Seto <[seto.hidetoshi@jp.fujitsu.com]>2009-08-06 14:51:57 -0700
committerTony Luck <tony.luck@intel.com>2009-09-14 16:18:17 -0700
commit6cc3efcdf01cf874ffe770919395918a3ee9365b (patch)
tree96a04f965ea57eaba6625f5d91e069563ad6ebbc /arch/m32r
parent07a6a4ae827b54cec4c1b1d92bed1cc9176b45ec (diff)
[IA64] kexec: Unregister MCA handler before kexec
Summary: MCA on the beginning of kdump/kexec kernel will result in unexpected behavior because MCA handler for previous kernel is invoked on the kdump kernel. Description: Once a cpu is passed to new kernel, all resources in previous kernel should not be used from the cpu. Even the resources for MCA handler are no exception. So we cannot handle MCAs and its machine check errors during kernel transition, until new handler for new kernel is registered with new resources ready for handling the MCA. How to reproduce: Assert MCA while kdump kernel is booting, before new MCA handler for kdump kernel is registered. Expected(Desirable) results: No recovery, cancel kdump and reboot the system. Actual results: MCA handler for previous kernel is invoked on the kdump kernel. => panic, hang etc. (unexpected) Proposed fix: To avoid entering MCA handler from early stage of new kernel, unregister the entry point from SAL before leave from current kernel. Then SAL will make all MCAs to warmboot safely, without invoking OS_MCA. 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>
Diffstat (limited to 'arch/m32r')
0 files changed, 0 insertions, 0 deletions