1. 29 10月, 2009 1 次提交
    • T
      percpu: make percpu symbols in xen unique · c6e22f9e
      Tejun Heo 提交于
      This patch updates percpu related symbols in xen 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/x86/xen/smp.c, arch/x86/xen/time.c, arch/ia64/xen/irq_xen.c:
        add xen_ prefix to percpu variables
      
      * arch/ia64/xen/time.c: add xen_ prefix to percpu variables, drop
        processed_ prefix and make them static
      
      Partly based on Rusty Russell's "alloc_percpu: rename percpu vars
      which cause name clashes" patch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
      Cc: Chris Wright <chrisw@sous-sol.org>
      c6e22f9e
  2. 02 10月, 2009 4 次提交
    • T
      ia64: convert to dynamic percpu allocator · 52594762
      Tejun Heo 提交于
      Unlike other archs, ia64 reserves space for percpu areas during early
      memory initialization.  These areas occupy a contiguous region indexed
      by cpu number on contiguous memory model or are grouped by node on
      discontiguous memory model.
      
      As allocation and initialization are done by the arch code, all that
      setup_per_cpu_areas() needs to do is communicating the determined
      layout to the percpu allocator.  This patch implements
      setup_per_cpu_areas() for both contig and discontig memory models and
      drops HAVE_LEGACY_PER_CPU_AREA.
      
      Please note that for contig model, the allocation itself is modified
      only to allocate for possible cpus instead of NR_CPUS.  As dynamic
      percpu allocator can handle non-direct mapping, there's no reason to
      allocate memory for cpus which aren't possible.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NTony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: linux-ia64 <linux-ia64@vger.kernel.org>
      52594762
    • T
      ia64: allocate percpu area for cpu0 like percpu areas for other cpus · 36886478
      Tejun Heo 提交于
      cpu0 used special percpu area reserved by the linker, __cpu0_per_cpu,
      which is set up early in boot by head.S.  However, this doesn't
      guarantee that the area will be on the same node as cpu0 and the
      percpu area for cpu0 ends up very far away from percpu areas for other
      cpus which cause problems for congruent percpu allocator.
      
      This patch makes percpu area initialization allocate percpu area for
      cpu0 like any other cpus and copy it from __cpu0_per_cpu which now
      resides in the __init area.  This means that for cpu0, percpu area is
      first setup at __cpu0_per_cpu early by head.S and then moved to an
      area in the linear mapping during memory initialization and it's not
      allowed to take a pointer to percpu variables between head.S and
      memory initialization.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NTony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: linux-ia64 <linux-ia64@vger.kernel.org>
      36886478
    • T
      ia64: initialize cpu maps early · 12cda817
      Tejun Heo 提交于
      All information necessary to initialize cpu possible and present maps
      are available once early_acpi_boot_init() is complete.  Reorganize
      setup_arch() and acpi init functions such that,
      
      * CPU information is printed after LAPIC entries are parsed in
        early_acpi_boot_init().
      
      * smp_build_cpu_map() is called by setup_arch() instead of acpi
        functions.
      
      * smp_build_cpu_map() is called once all CPU related information is
        available before memory is initialized.
      
      This is primarily to allow find_memory() to use cpu maps but is also a
      general cleanup.  Please note that with this change, the somewhat
      ad-hoc early_cpu_possible_map defined and used for NUMA configurations
      is probably unnecessary.  Something to clean up another day.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NTony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: linux-ia64 <linux-ia64@vger.kernel.org>
      12cda817
    • T
      ia64: don't alias VMALLOC_END to vmalloc_end · 126b3fcd
      Tejun Heo 提交于
      If CONFIG_VIRTUAL_MEM_MAP is enabled, ia64 defines macro VMALLOC_END
      as unsigned long variable vmalloc_end which is adjusted to prepare
      room for vmemmap.  This becomes probnlematic if a local variables
      vmalloc_end is defined in some function (not very unlikely) and
      VMALLOC_END is used in the function - the function thinks its
      referencing the global VMALLOC_END value but would be referencing its
      own local vmalloc_end variable.
      
      There's no reason VMALLOC_END should be a macro.  Just define it as an
      unsigned long variable if CONFIG_VIRTUAL_MEM_MAP is set to avoid nasty
      surprises.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NTony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: linux-ia64 <linux-ia64@vger.kernel.org>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      126b3fcd
  3. 28 9月, 2009 1 次提交
  4. 27 9月, 2009 1 次提交
  5. 25 9月, 2009 1 次提交
    • T
      [IA64] implement ticket locks for Itanium · 2c86963b
      Tony Luck 提交于
      Back in January 2008 Nick Piggin implemented "ticket" spinlocks
      for X86 (See commit 314cdbef).
      
      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: NTony Luck <tony.luck@intel.com>
      2c86963b
  6. 24 9月, 2009 4 次提交
  7. 23 9月, 2009 4 次提交
  8. 22 9月, 2009 3 次提交
  9. 21 9月, 2009 2 次提交
  10. 20 9月, 2009 2 次提交
    • S
      kbuild: rename ld-option to cc-ldoption · f86fd306
      Sam Ravnborg 提交于
      ld-option is misnamed as it test options to gcc, not to ld.
      Renamed it to reflect this.
      
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Roland McGrath <roland@redhat.com>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      f86fd306
    • S
      kbuild: use INSTALLKERNEL to select customized installkernel script · caa27b66
      Sam Ravnborg 提交于
      Replace the use of CROSS_COMPILE to select a customized
      installkernel script with the possibility to set INSTALLKERNEL
      to select a custom installkernel script when running make:
      
          make INSTALLKERNEL=arm-installkernel install
      
      With this patch we are now more consistent across
      different architectures - they did not all support use
      of CROSS_COMPILE.
      
      The use of CROSS_COMPILE was a hack as this really belongs
      to gcc/binutils and the installkernel script does not change
      just because we change toolchain.
      
      The use of CROSS_COMPILE caused troubles with an upcoming patch
      that saves CROSS_COMPILE when a kernel is built - it would no
      longer be installable.
      [Thanks to Peter Z. for this hint]
      
      This patch undos what Ian did in commit:
      
        0f8e2d62
        ("use ${CROSS_COMPILE}installkernel in arch/*/boot/install.sh")
      
      The patch has been lightly tested on x86 only - but all changes
      looks obvious.
      Acked-by: NPeter Zijlstra <peterz@infradead.org>
      Acked-by: Mike Frysinger <vapier@gentoo.org> [blackfin]
      Acked-by: Russell King <linux@arm.linux.org.uk> [arm]
      Acked-by: Paul Mundt <lethal@linux-sh.org> [sh]
      Acked-by: "H. Peter Anvin" <hpa@zytor.com> [x86]
      Cc: Ian Campbell <icampbell@arcom.com>
      Cc: Tony Luck <tony.luck@intel.com> [ia64]
      Cc: Fenghua Yu <fenghua.yu@intel.com> [ia64]
      Cc: Hirokazu Takata <takata@linux-m32r.org> [m32r]
      Cc: Geert Uytterhoeven <geert@linux-m68k.org> [m68k]
      Cc: Kyle McMartin <kyle@mcmartin.ca> [parisc]
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> [powerpc]
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> [s390]
      Cc: Thomas Gleixner <tglx@linutronix.de> [x86]
      Cc: Ingo Molnar <mingo@redhat.com> [x86]
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      caa27b66
  11. 17 9月, 2009 1 次提交
  12. 16 9月, 2009 4 次提交
  13. 15 9月, 2009 12 次提交
    • J
      [IA64] pci_br, fix infinite loop in find_free_ate() · 9b6b9399
      Jiri Slaby 提交于
      When
      * there is almost out of ates
      * one asks for more than one ate
      * there are some available at the end of ate array
      then the inner for loop will end without incrementing 'index'. This
      means the outer loop will start at the same point finding it's available
      and runs the inner loop again from the same index. This repeats forever.
      
      Hence make sure we check we were at the end of ate array and return
      an error in such case.
      Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Found-by: NJeff Mahoney <jeffm@novell.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      9b6b9399
    • P
      sched: Reduce forkexec_idx · b8a543ea
      Peter Zijlstra 提交于
      If we're looking to place a new task, we might as well find the
      idlest position _now_, not 1 tick ago.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b8a543ea
    • M
      sched: Improve latencies and throughput · 0ec9fab3
      Mike Galbraith 提交于
      Make the idle balancer more agressive, to improve a
      x264 encoding workload provided by Jason Garrett-Glaser:
      
       NEXT_BUDDY NO_LB_BIAS
       encoded 600 frames, 252.82 fps, 22096.60 kb/s
       encoded 600 frames, 250.69 fps, 22096.60 kb/s
       encoded 600 frames, 245.76 fps, 22096.60 kb/s
      
       NO_NEXT_BUDDY LB_BIAS
       encoded 600 frames, 344.44 fps, 22096.60 kb/s
       encoded 600 frames, 346.66 fps, 22096.60 kb/s
       encoded 600 frames, 352.59 fps, 22096.60 kb/s
      
       NO_NEXT_BUDDY NO_LB_BIAS
       encoded 600 frames, 425.75 fps, 22096.60 kb/s
       encoded 600 frames, 425.45 fps, 22096.60 kb/s
       encoded 600 frames, 422.49 fps, 22096.60 kb/s
      
      Peter pointed out that this is better done via newidle_idx,
      not via LB_BIAS, newidle balancing should look for where
      there is load _now_, not where there was load 2 ticks ago.
      
      Worst-case latencies are improved as well as no buddies
      means less vruntime spread. (as per prior lkml discussions)
      
      This change improves kbuild-peak parallelism as well.
      Reported-by: NJason Garrett-Glaser <darkshikari@gmail.com>
      Signed-off-by: NMike Galbraith <efault@gmx.de>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1253011667.9128.16.camel@marge.simson.net>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0ec9fab3
    • P
      sched: Tweak wake_idx · 78e7ed53
      Peter Zijlstra 提交于
      When merging select_task_rq_fair() and sched_balance_self() we lost
      the use of wake_idx, restore that and set them to 0 to make wake
      balancing more aggressive.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      78e7ed53
    • P
      sched: Merge select_task_rq_fair() and sched_balance_self() · c88d5910
      Peter Zijlstra 提交于
      The problem with wake_idle() is that is doesn't respect things like
      cpu_power, which means it doesn't deal well with SMT nor the recent
      RT interaction.
      
      To cure this, it needs to do what sched_balance_self() does, which
      leads to the possibility of merging select_task_rq_fair() and
      sched_balance_self().
      
      Modify sched_balance_self() to:
      
        - update_shares() when walking up the domain tree,
          (it only called it for the top domain, but it should
           have done this anyway), which allows us to remove
          this ugly bit from try_to_wake_up().
      
        - do wake_affine() on the smallest domain that contains
          both this (the waking) and the prev (the wakee) cpu for
          WAKE invocations.
      
      Then use the top-down balance steps it had to replace wake_idle().
      
      This leads to the dissapearance of SD_WAKE_BALANCE and
      SD_WAKE_IDLE_FAR, with SD_WAKE_IDLE replaced with SD_BALANCE_WAKE.
      
      SD_WAKE_AFFINE needs SD_BALANCE_WAKE to be effective.
      
      Touch all topology bits to replace the old with new SD flags --
      platforms might need re-tuning, enabling SD_BALANCE_WAKE
      conditionally on a NUMA distance seems like a good additional
      feature, magny-core and small nehalem systems would want this
      enabled, systems with slow interconnects would not.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c88d5910
    • A
      cleanup console_print() · 353f6dd2
      Anirban Sinha 提交于
      console_print() is an old legacy interface mostly unused in the entire
      kernel tree. It's best to clean up its existing use and let developers
      use their own implementation of it as they feel fit.
      Signed-off-by: NAnirban Sinha <asinha@zeugmasystems.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      353f6dd2
    • H
      [IA64] kdump: Short path to freeze CPUs · 0cced40e
      Hidetoshi Seto 提交于
      Setting monarch_cpu = -1 to let slaves frozen might not work, because
      there might be slaves being late, not entered the rendezvous yet.
      Such slaves might be caught in while (monarch_cpu == -1) loop.
      
      Use kdump_in_progress instead of monarch_cpus to break INIT rendezvous
      and let all slaves enter DIE_INIT_SLAVE_LEAVE smoothly.
      
      And monarch no longer need to manage rendezvous if once kdump_in_progress
      is set, catch the monarch in DIE_INIT_MONARCH_ENTER then.
      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>
      0cced40e
    • H
      [IA64] kdump: Try INIT regardless of · 5959906e
      Hidetoshi Seto 提交于
      kdump_on_init
      
      CPUs should be frozen if possible, otherwise it might hinder kdump.
      So if there are CPUs not respond to IPI, try INIT to stop them.
      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>
      5959906e
    • 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
    • H
      [IA64] kdump: Don't return APs to SAL from kdump · 68cb14c7
      Hidetoshi Seto 提交于
      Summary:
      
        Asserting INIT on cpu going to be offline will result in unexpected
        behavior.  It will be a real problem in kdump cases where INIT might
        be asserted to unstable APs going to be offline by returning to SAL.
      
      Description:
      
        Since psr.mc is cleared when bits in psr are set to SAL_PSR_BITS_TO_SET
        in ia64_jump_to_sal(), there is a small window (~few msecs) that the
        cpu can receive INIT even if the cpu enter there via INIT handler.
        In this window we do restore of registers for SAL, so INIT asserted
        here will not work properly.
      
        It is hard to remove this window by masking INIT (i.e. setting psr.mc)
        because we have to unmask it later in OS, because we have to use branch
        instruction (br.ret, not rfi) to return SAL, due to OS_BOOT_RENDEZ to
        SAL return convention.
      
        I suppose this window will not be a real problem on cpu offline if we
        can educate people not to push INIT button during hotplug operation.
        However, only exception is a race in kdump and INIT.  Now kdump returns
        APs to SAL before processing dump, but the kernel might receive INIT at
        that point in time.  Such INIT might be asserted by kdump itself if an
        AP doesn't react IPI soon and kdump decided to use INIT to stop the AP.
        Or it might be asserted by operator or an external agent to start dump
        on the unstable system.
      
        Such panic+INIT or INIT+INIT cases should be rare, but it will be happy
        if we can retrieve crashdump even in such cases.
      
      How to reproduce:
      
        panic+INIT or INIT+INIT, with kdump configured
      
      Expected results:
      
        crashdump is retrieved anyway
      
      Actual results:
      
        panic, hang etc. (unexpected)
      
      Proposed fix
      
        To avoid the window on the way to SAL, this patch stops returning APs
        to SAL in case of kdump.  In other words, this patch makes APs spin
        in OS instead of spinning in SAL.
      
        (* Note: What impact would be there?  If a cpu is spinning in SAL,
         the cpu is in BOOT_RENDEZ loop, as same as offlined cpu.
         In theory if an INIT is asserted there, cpus in the BOOT_RENDEZ loop
         should not invoke OS_INIT on it.  So in either way, no matter where
         the cpu is spinning actually in, once cpu starts spin and act as
         "frozen," INIT on the cpu have no effects.
         From another point of view, all debug information on the cpu should
         have stored to memory before the cpu start to be frozen.  So no more
         action on the cpu is required.)
      
        I confirmed that the kdump sometime hangs by concurrent INITs (another
        INIT after an INIT), and it doesn't hang after applying this patch.
      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>
      68cb14c7
    • H
      [IA64] kexec: Unregister MCA handler before kexec · 6cc3efcd
      Hidetoshi Seto 提交于
      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: 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>
      6cc3efcd
    • H
      [IA64] kexec: Make INIT safe while transition to · 07a6a4ae
      Hidetoshi Seto 提交于
      kdump/kexec kernel
      
      Summary:
      
        Asserting INIT on the beginning of kdump/kexec kernel will result
        in unexpected behavior because INIT handler for previous kernel is
        invoked on new kernel.
      
      Description:
      
        In panic situation, we can receive INIT while kernel transition,
        i.e. from beginning of panic to bootstrap of kdump kernel.
        Since we initialize registers on leave from current kernel, no
        longer monarch/slave handlers of current kernel in virtual mode are
        called safely.  (In fact system goes hang as far as I confirmed)
      
      How to Reproduce:
      
        Start kdump
          # echo c > /proc/sysrq-trigger
        Then assert INIT while kdump kernel is booting, before new INIT
        handler for kdump kernel is registered.
      
      Expected(Desirable) result:
      
        kdump kernel boots without any problem, crashdump retrieved
      
      Actual result:
      
        INIT handler for previous kernel is invoked on kdump kernel
        => panic, hang etc. (unexpected)
      
      Proposed fix:
      
        We can unregister these init handlers from SAL before jumping into
        new kernel, however then the INIT will fallback to default behavior,
        result in warmboot by SAL (according to the SAL specification) and
        we cannot retrieve the crashdump.
      
        Therefore this patch introduces a NOP init handler and register it
        to SAL before leave from current kernel, to start kdump safely by
        preventing INITs from entering virtual mode and resulting in warmboot.
      
        On the other hand, in case of kexec that not for kdump, it also
        has same problem with INIT while kernel transition.
        This patch handles this case differently, because for kexec
        unregistering handlers will be preferred than registering NOP
        handler, since the situation "no handlers registered" is usual
        state for kernel's entry.
      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>
      07a6a4ae