1. 16 4月, 2015 1 次提交
    • J
      kernel/reboot.c: add orderly_reboot for graceful reboot · 7a54f46b
      Joel Stanley 提交于
      The kernel has orderly_poweroff which allows the kernel to initiate a
      graceful shutdown of userspace, by running /sbin/poweroff.  This adds
      orderly_reboot that will cause userspace to shut itself down by calling
      /sbin/reboot.
      
      This will be used for shutdown initiated by a system controller on
      platforms that do not use ACPI.
      
      orderly_reboot() should be used when the system wants to allow userspace
      to gracefully shut itself down.  For cases where the system may imminently
      catch on fire, the existing emergency_restart() provides an immediate
      reboot without involving userspace.
      Signed-off-by: NJoel Stanley <joel@jms.id.au>
      Cc: Fabian Frederick <fabf@skynet.be>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Jeremy Kerr <jk@ozlabs.org>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7a54f46b
  2. 26 9月, 2014 1 次提交
    • G
      kernel: add support for kernel restart handler call chain · b63adb97
      Guenter Roeck 提交于
      Various drivers implement architecture and/or device specific means to
      restart (reset) the system.  Various mechanisms have been implemented to
      support those schemes.  The best known mechanism is arm_pm_restart, which
      is a function pointer to be set either from platform specific code or from
      drivers.  Another mechanism is to use hardware watchdogs to issue a reset;
      this mechanism is used if there is no other method available to reset a
      board or system.  Two examples are alim7101_wdt, which currently uses the
      reboot notifier to trigger a reset, and moxart_wdt, which registers the
      arm_pm_restart function.
      
      The existing mechanisms have a number of drawbacks.  Typically only one
      scheme to restart the system is supported (at least if arm_pm_restart is
      used).  At least in theory there can be multiple means to restart the
      system, some of which may be less desirable (for example one mechanism may
      only reset the CPU, while another may reset the entire system).  Using
      arm_pm_restart can also be racy if the function pointer is set from a
      driver, as the driver may be in the process of being unloaded when
      arm_pm_restart is called.  Using the reboot notifier is always racy, as it
      is unknown if and when other functions using the reboot notifier have
      completed execution by the time the watchdog fires.
      
      Introduce a system restart handler call chain to solve the described
      problems.  This call chain is expected to be executed from the
      architecture specific machine_restart() function.  Drivers providing
      system restart functionality (such as the watchdog drivers mentioned
      above) are expected to register with this call chain.  By using the
      priority field in the notifier block, callers can control restart handler
      execution sequence and thus ensure that the restart handler with the
      optimal restart capabilities for a given system is called first.
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: NHeiko Stuebner <heiko@sntech.de>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Wim Van Sebroeck <wim@iguana.be>
      Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Jonas Jensen <jonas.jensen@gmail.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Tomasz Figa <t.figa@samsung.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      b63adb97
  3. 16 4月, 2014 1 次提交
    • I
      x86: Remove the PCI reboot method from the default chain · 5be44a6f
      Ingo Molnar 提交于
      Steve reported a reboot hang and bisected it back to this commit:
      
        a4f1987e x86, reboot: Add EFI and CF9 reboot methods into the default list
      
      He heroically tested all reboot methods and found the following:
      
        reboot=t       # triple fault                  ok
        reboot=k       # keyboard ctrl                 FAIL
        reboot=b       # BIOS                          ok
        reboot=a       # ACPI                          FAIL
        reboot=e       # EFI                           FAIL   [system has no EFI]
        reboot=p       # PCI 0xcf9                     FAIL
      
      And I think it's pretty obvious that we should only try PCI 0xcf9 as a
      last resort - if at all.
      
      The other observation is that (on this box) we should never try
      the PCI reboot method, but close with either the 'triple fault'
      or the 'BIOS' (terminal!) reboot methods.
      
      Thirdly, CF9_COND is a total misnomer - it should be something like
      CF9_SAFE or CF9_CAREFUL, and 'CF9' should be 'CF9_FORCE' ...
      
      So this patch fixes the worst problems:
      
       - it orders the actual reboot logic to follow the reboot ordering
         pattern - it was in a pretty random order before for no good
         reason.
      
       - it fixes the CF9 misnomers and uses BOOT_CF9_FORCE and
         BOOT_CF9_SAFE flags to make the code more obvious.
      
       - it tries the BIOS reboot method before the PCI reboot method.
         (Since 'BIOS' is a terminal reboot method resulting in a hang
          if it does not work, this is essentially equivalent to removing
          the PCI reboot method from the default reboot chain.)
      
       - just for the miraculous possibility of terminal (resulting
         in hang) reboot methods of triple fault or BIOS returning
         without having done their job, there's an ordering between
         them as well.
      Reported-and-bisected-and-tested-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: Li Aubrey <aubrey.li@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Link: http://lkml.kernel.org/r/20140404064120.GB11877@gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      5be44a6f
  4. 19 12月, 2013 1 次提交
  5. 10 7月, 2013 5 次提交
  6. 13 10月, 2012 1 次提交
  7. 26 7月, 2011 1 次提交
  8. 13 3月, 2010 1 次提交
  9. 15 8月, 2008 1 次提交
  10. 06 2月, 2008 1 次提交
  11. 18 7月, 2007 1 次提交
    • J
      Add common orderly_poweroff() · 10a0a8d4
      Jeremy Fitzhardinge 提交于
      Various pieces of code around the kernel want to be able to trigger an
      orderly poweroff.  This pulls them together into a single
      implementation.
      
      By default the poweroff command is /sbin/poweroff, but it can be set
      via sysctl: kernel/poweroff_cmd.  This is split at whitespace, so it
      can include command-line arguments.
      
      This patch replaces four other instances of invoking either "poweroff"
      or "shutdown -h now": two sbus drivers, and acpi thermal
      management.
      
      sparc64 has its own "powerd"; still need to determine whether it should
      be replaced by orderly_poweroff().
      Signed-off-by: NJeremy Fitzhardinge <jeremy@xensource.com>
      Acked-by: NLen Brown <lenb@kernel.org>
      Signed-off-by: NChris Wright <chrisw@sous-sol.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: David S. Miller <davem@davemloft.net>
      10a0a8d4
  12. 26 6月, 2006 1 次提交
  13. 16 12月, 2005 1 次提交
  14. 23 9月, 2005 1 次提交
  15. 27 7月, 2005 2 次提交
  16. 26 6月, 2005 2 次提交
  17. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4