1. 15 Jan, 2019 1 commit
  2. 12 Jul, 2017 1 commit
  3. 05 Apr, 2017 1 commit
  4. 21 Sep, 2016 2 commits
  5. 03 Jun, 2016 1 commit
  6. 24 May, 2016 1 commit
  7. 03 May, 2016 1 commit
    • Russell King's avatar
      ARM: kexec: fix crashkernel= handling · 61603016
      Russell King authored
      When the kernel crashkernel parameter is specified with just a size, we
      are supposed to allocate a region from RAM to store the crashkernel.
      However, ARM merely reserves physical address zero with no checking that
      there is even RAM there.
      
      Fix this by lifting similar code from x86, importing it to ARM with the
      ARM specific parameters added.  In the absence of any platform specific
      information, we allocate the crashkernel region from the first 512MB of
      physical memory.
      
      Update the kdump documentation to reflect this change.
      Signed-off-by: 's avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Reviewed-by: 's avatarPratyush Anand <panand@redhat.com>
      61603016
  8. 11 Dec, 2014 1 commit
    • Prarit Bhargava's avatar
      kernel: add panic_on_warn · 9e3961a0
      Prarit Bhargava authored
      There have been several times where I have had to rebuild a kernel to
      cause a panic when hitting a WARN() in the code in order to get a crash
      dump from a system.  Sometimes this is easy to do, other times (such as
      in the case of a remote admin) it is not trivial to send new images to
      the user.
      
      A much easier method would be a switch to change the WARN() over to a
      panic.  This makes debugging easier in that I can now test the actual
      image the WARN() was seen on and I do not have to engage in remote
      debugging.
      
      This patch adds a panic_on_warn kernel parameter and
      /proc/sys/kernel/panic_on_warn calls panic() in the
      warn_slowpath_common() path.  The function will still print out the
      location of the warning.
      
      An example of the panic_on_warn output:
      
      The first line below is from the WARN_ON() to output the WARN_ON()'s
      location.  After that the panic() output is displayed.
      
          WARNING: CPU: 30 PID: 11698 at /home/prarit/dummy_module/dummy-module.c:25 init_dummy+0x1f/0x30 [dummy_module]()
          Kernel panic - not syncing: panic_on_warn set ...
      
          CPU: 30 PID: 11698 Comm: insmod Tainted: G        W  OE  3.17.0+ #57
          Hardware name: Intel Corporation S2600CP/S2600CP, BIOS RMLSDP.86I.00.29.D696.1311111329 11/11/2013
           0000000000000000 000000008e3f87df ffff88080f093c38 ffffffff81665190
           0000000000000000 ffffffff818aea3d ffff88080f093cb8 ffffffff8165e2ec
           ffffffff00000008 ffff88080f093cc8 ffff88080f093c68 000000008e3f87df
          Call Trace:
           [<ffffffff81665190>] dump_stack+0x46/0x58
           [<ffffffff8165e2ec>] panic+0xd0/0x204
           [<ffffffffa038e05f>] ? init_dummy+0x1f/0x30 [dummy_module]
           [<ffffffff81076b90>] warn_slowpath_common+0xd0/0xd0
           [<ffffffffa038e040>] ? dummy_greetings+0x40/0x40 [dummy_module]
           [<ffffffff81076c8a>] warn_slowpath_null+0x1a/0x20
           [<ffffffffa038e05f>] init_dummy+0x1f/0x30 [dummy_module]
           [<ffffffff81002144>] do_one_initcall+0xd4/0x210
           [<ffffffff811b52c2>] ? __vunmap+0xc2/0x110
           [<ffffffff810f8889>] load_module+0x16a9/0x1b30
           [<ffffffff810f3d30>] ? store_uevent+0x70/0x70
           [<ffffffff810f49b9>] ? copy_module_from_fd.isra.44+0x129/0x180
           [<ffffffff810f8ec6>] SyS_finit_module+0xa6/0xd0
           [<ffffffff8166cf29>] system_call_fastpath+0x12/0x17
      
      Successfully tested by me.
      
      hpa said: There is another very valid use for this: many operators would
      rather a machine shuts down than being potentially compromised either
      functionally or security-wise.
      Signed-off-by: 's avatarPrarit Bhargava <prarit@redhat.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Acked-by: 's avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: Fabian Frederick <fabf@skynet.be>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      9e3961a0
  9. 29 Aug, 2014 1 commit
  10. 03 Jul, 2013 1 commit
  11. 28 May, 2013 1 commit
  12. 02 Apr, 2013 1 commit
    • Xishi Qiu's avatar
      Add size restriction to the kdump documentation · 797f6a68
      Xishi Qiu authored
      In efi_init() memory aligns in IA64_GRANULE_SIZE(16M). If set "crashkernel=1024M-:600M"
      and use sparse memory model, when crash kernel booting it changes [128M-728M] to [128M-720M].
      
      But initrd memory is in [709M-727M], and virt_addr_valid() *can not* check the invalid pages
      when freeing initrd memory, because there are some pages missed at the end of the section,
      and this causes error.
      
      ...
      Unpacking initramfs...
      Freeing initrd memory: 19648kB freed
      BUG: Bad page state in process swapper  pfn:02d00
      page:e0000000102dd800 flags:(null) count:0 mapcount:1 mapping:(null) index:0
      
      Call Trace:
       [<a000000100018dc0>] show_stack+0x80/0xa0
                                      sp=e000000021e8fbd0 bsp=e000000021e81360
       [<a00000010090fcc0>] dump_stack+0x30/0x50
                                      sp=e000000021e8fda0 bsp=e000000021e81348
       [<a0000001001a3180>] bad_page+0x280/0x380
                                      sp=e000000021e8fda0 bsp=e000000021e81308
       [<a0000001001a8740>] free_hot_cold_page+0x3a0/0x5c0
                                      sp=e000000021e8fda0 bsp=e000000021e812a0
       [<a0000001001a8a50>] free_hot_page+0x30/0x60
                                      sp=e000000021e8fda0 bsp=e000000021e81280
       [<a0000001001a8b30>] __free_pages+0xb0/0xe0
                                      sp=e000000021e8fda0 bsp=e000000021e81258
       [<a0000001001a8c00>] free_pages+0xa0/0xc0
                                      sp=e000000021e8fda0 bsp=e000000021e81230
       [<a000000100bb40c0>] free_initrd_mem+0x230/0x290
                                      sp=e000000021e8fda0 bsp=e000000021e811d8
       [<a000000100ba6620>] populate_rootfs+0x1c0/0x280
                                      sp=e000000021e8fdb0 bsp=e000000021e811a0
       [<a00000010000ac30>] do_one_initcall+0x3b0/0x3e0
                                      sp=e000000021e8fdb0 bsp=e000000021e81158
       [<a000000100ba0a90>] kernel_init+0x3f0/0x4b0
                                      sp=e000000021e8fdb0 bsp=e000000021e81108
       [<a000000100016890>] kernel_thread_helper+0xd0/0x100
                                      sp=e000000021e8fe30 bsp=e000000021e810e0
       [<a00000010000a4c0>] start_kernel_thread+0x20/0x40
                                      sp=e000000021e8fe30 bsp=e000000021e810e0
      ...
      
      In "http://marc.info/?l=linux-arch&m=136147092429314&w=2" Tony said:
      "Perhaps in Documentation/kdump/kdump.txt (which the crashkernel entry
      in kernel-parameters.txt points at).  The ia64 section of kdump.txt
      notes that the start address will be rounded up to a GRANULE boundary,
      but doesn't talk about restrictions on the size."
      
      This patch add size restriction to the documentation of kdump.
      Signed-off-by: 's avatarXishi Qiu <qiuxishi@huawei.com>
      Signed-off-by: 's avatarTony Luck <tony.luck@intel.com>
      797f6a68
  13. 19 Jul, 2012 1 commit
  14. 27 Dec, 2011 1 commit
  15. 25 Nov, 2010 1 commit
  16. 12 Jun, 2009 1 commit
  17. 22 Oct, 2008 1 commit
    • Mohan Kumar M's avatar
      powerpc: Support for relocatable kdump kernel · 54622f10
      Mohan Kumar M authored
      This adds relocatable kernel support for kdump. With this one can
      use the same regular kernel to capture the kdump. A signature (0xfeed1234)
      is passed in r6 from panic code to the next kernel through kexec_sequence
      and purgatory code. The signature is used to differentiate between
      kdump kernel and non-kdump kernels.
      
      The purgatory code compares the signature and sets the __kdump_flag in
      head_64.S.  During the boot up, kernel code checks __kdump_flag and if it
      is set, the kernel will behave as relocatable kdump kernel. This kernel
      will boot at the address where it was loaded by kexec-tools ie. at the
      address reserved through crashkernel boot parameter.
      
      CONFIG_CRASH_DUMP depends on CONFIG_RELOCATABLE option to build kdump
      kernel as relocatable. So the same kernel can be used as production and
      kdump kernel.
      
      This patch incorporates the changes suggested by Paul Mackerras to avoid
      GOT use and to avoid two copies of the code.
      Signed-off-by: 's avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: 's avatarMohan Kumar M <mohan@in.ibm.com>
      Signed-off-by: 's avatarMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: 's avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      54622f10
  18. 28 Jul, 2008 1 commit
  19. 08 Jul, 2008 1 commit
  20. 01 May, 2008 1 commit
  21. 19 Oct, 2007 1 commit
  22. 17 Oct, 2007 4 commits
  23. 21 Feb, 2007 1 commit
  24. 12 Feb, 2007 1 commit
  25. 23 Jan, 2007 2 commits
  26. 12 Jan, 2007 1 commit
  27. 03 Oct, 2006 1 commit
  28. 26 Jun, 2006 1 commit
  29. 25 Jun, 2006 1 commit
  30. 12 Jan, 2006 1 commit
  31. 10 Jan, 2006 1 commit
  32. 13 Sep, 2005 1 commit
  33. 09 Sep, 2005 1 commit
  34. 25 Jun, 2005 2 commits
    • Vivek Goyal's avatar
      [PATCH] kdump documentation update to introduce use of irqpoll · d58831e4
      Vivek Goyal authored
      o Specify "irqpoll" command line option which loading second kernel. This
        helps in reducing driver initialization failures in second kernel due
        to shared interrupts.
      o Enabled LAPIC/IOAPIC support for UP kernels in second kernel. This reduces
        the chances of devices sharing the irq and hence reduces the chances of
        driver initialization failures in second kernel.
      o Build a UP capture kernel and disabled SMP support.
      Signed-off-by: 's avatarVivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: 's avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@osdl.org>
      d58831e4
    • Vivek Goyal's avatar
      [PATCH] kdump: Documentation for Kdump · b089f4a6
      Vivek Goyal authored
      This patch contains the documentation for the kexec based crash dump tool.
      
      Quick kdump-howto
      ================================================================
      
      1) Download and build kexec-tools.
      
      2) Download and build the latest kexec/kdump (-mm) kernel patchset.
         Two kernels need to be built in order to get this feature working.
      
        A) First kernel:
         a) Enable "kexec system call" feature:
      	CONFIG_KEXEC=y
         b) Physical load address (use default):
      	CONFIG_PHYSICAL_START=0x100000
         c) Enable "sysfs file system support":
      	CONFIG_SYSFS=y
         d) Boot into first kernel with the command line parameter "crashkernel=Y@X":
            For example: "crashkernel=64M@16M".
      
        B) Second kernel:
         a) Enable "kernel crash dumps" feature:
      	CONFIG_CRASH_DUMP=y
         b) Physical load addreess, use same load address as X in "crashkernel"
            kernel parameter in d) above, e.g., 16 MB or 0x1000000.
      	CONFIG_PHYSICAL_START=0x1000000
         c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems).
      	CONFIG_PROC_VMCORE=y
      
      3) Boot into the first kernel.
      
      4) Load the second kernel to be booted using:
      
         kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev>
         maxcpus=1 init 1"
      
      5) System reboots into the second kernel when a panic occurs. A module can be
         written to force the panic, for testing purposes.
      
      6) See Documentation/kdump.txt for how to read the first kernel's
         memory image and how to analyze it.
      Signed-off-by: 's avatarHariprasad Nellitheertha <hari@in.ibm.com>
      Signed-off-by: 's avatarEric Biederman <ebiederm@xmission.com>
      Signed-off-by: 's avatarVivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: 's avatarrandy_dunlap <rdunlap@xenotime.net>
      Signed-off-by: 's avatarManeesh Soni <maneesh@in.ibm.com>
      Signed-off-by: 's avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@osdl.org>
      b089f4a6