1. 15 9月, 2009 1 次提交
    • H
      [IA64] kdump: Mask INIT first in panic-kdump path · 1726b088
      Hidetoshi Seto 提交于
      Summary:
      
        Asserting INIT might block kdump if the system is already going to
        start kdump via panic.
      
      Description:
      
        INIT can interrupt anywhere in panic path, so it can interrupt in
        middle of kdump kicked by panic.  Therefore there is a race if kdump
        is kicked concurrently, via Panic and via INIT.
      
        INIT could fail to invoke kdump if the system is already going to
        start kdump via panic.  It could not restart kdump from INIT handler
        if some of cpus are already playing dead with INIT masked.  It also
        means that INIT could block kdump's progress if no monarch is entered
        in the INIT rendezvous.
      
        Panic+INIT is a rare, but possible situation since it can be assumed
        that the kernel or an internal agent decides to panic the unstable
        system while another external agent decides to send an INIT to the
        system at same time.
      
      How to reproduce:
      
        Assert INIT just after panic, before all other cpus have frozen
      
      Expected results:
      
        continue kdump invoked by panic, or restart kdump from INIT
      
      Actual results:
      
        might be hang, crashdump not retrieved
      
      Proposed Fix:
      
        This patch masks INIT first in panic path to take the initiative on
        kdump, and reuse atomic value kdump_in_progress to make sure there is
        only one initiator of kdump.  All INITs asserted later should be used
        only for freezing all other cpus.
      
        This mask will be removed soon by rfi in relocate_kernel.S, before jump
        into kdump kernel, after all cpus are frozen and no-op INIT handler is
        registered.  So if INIT was in the interval while it is masked, it will
        pend on the system and will received just after the rfi, and handled by
        the no-op handler.
      
        If there was a MCA event while psr.mc is 1, in theory the event will
        pend on the system and will received just after the rfi same as above.
        MCA handler is unregistered here at the time, so received MCA will not
        reach to OS_MCA and will result in warmboot by SAL.
      
        Note that codes in this masked interval are relatively simpler than
        that in MCA/INIT handler which also executed with the mask.  So it can
        be said that probability of error in this interval is supposed not so
        higher than that in MCA/INIT handler.
      Signed-off-by: NHidetoshi 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: NFenghua Yu <fenghua.yu@intel.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      1726b088
  2. 09 5月, 2007 1 次提交
  3. 08 12月, 2006 1 次提交
    • Z
      [IA64] IA64 Kexec/kdump · a7956113
      Zou Nan hai 提交于
      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: NZou Nan hai <nanhai.zou@intel.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      a7956113