21 Sep, 2016

2 commits


04 Jun, 2016

1 commit

  • Commit 7ff9554bb578 ("printk: convert byte-buffer to variable-length
    record buffer") introduced a record based printk buffer. Modify
    gdbmacros.txt to parse this new structure so dmesg will work properly.

    Link: http://lkml.kernel.org/r/1463515794-1599-1-git-send-email-minyard@acm.org
    Signed-off-by: Corey Minyard
    Cc: Dave Young
    Cc: Baoquan He
    Cc: Vivek Goyal
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Corey Minyard
     

24 May, 2016

1 commit

  • Lots of little changes needed to be made to clean these up, remove the
    four byte pointer assumption and traverse the pid queue properly. Also
    consolidate the traceback code into a single function instead of having
    three copies of it.

    Link: http://lkml.kernel.org/r/1462926655-9390-1-git-send-email-minyard@acm.org
    Signed-off-by: Corey Minyard
    Acked-by: Baoquan He
    Cc: Vivek Goyal
    Cc: Haren Myneni
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Corey Minyard
     

03 May, 2016

1 commit

  • 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: Russell King
    Reviewed-by: Pratyush Anand

    Russell King
     

11 Dec, 2014

1 commit

  • 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:
    [] dump_stack+0x46/0x58
    [] panic+0xd0/0x204
    [] ? init_dummy+0x1f/0x30 [dummy_module]
    [] warn_slowpath_common+0xd0/0xd0
    [] ? dummy_greetings+0x40/0x40 [dummy_module]
    [] warn_slowpath_null+0x1a/0x20
    [] init_dummy+0x1f/0x30 [dummy_module]
    [] do_one_initcall+0xd4/0x210
    [] ? __vunmap+0xc2/0x110
    [] load_module+0x16a9/0x1b30
    [] ? store_uevent+0x70/0x70
    [] ? copy_module_from_fd.isra.44+0x129/0x180
    [] SyS_finit_module+0xa6/0xd0
    [] 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: Prarit Bhargava
    Cc: Jonathan Corbet
    Cc: Rusty Russell
    Cc: "H. Peter Anvin"
    Cc: Andi Kleen
    Cc: Masami Hiramatsu
    Acked-by: Yasuaki Ishimatsu
    Cc: Fabian Frederick
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Prarit Bhargava
     

30 Aug, 2014

1 commit


05 Jul, 2013

1 commit

  • Pull trivial tree updates from Jiri Kosina:
    "The usual stuff from trivial tree"

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (34 commits)
    treewide: relase -> release
    Documentation/cgroups/memory.txt: fix stat file documentation
    sysctl/net.txt: delete reference to obsolete 2.4.x kernel
    spinlock_api_smp.h: fix preprocessor comments
    treewide: Fix typo in printk
    doc: device tree: clarify stuff in usage-model.txt.
    open firmware: "/aliasas" -> "/aliases"
    md: bcache: Fixed a typo with the word 'arithmetic'
    irq/generic-chip: fix a few kernel-doc entries
    frv: Convert use of typedef ctl_table to struct ctl_table
    sgi: xpc: Convert use of typedef ctl_table to struct ctl_table
    doc: clk: Fix incorrect wording
    Documentation/arm/IXP4xx fix a typo
    Documentation/networking/ieee802154 fix a typo
    Documentation/DocBook/media/v4l fix a typo
    Documentation/video4linux/si476x.txt fix a typo
    Documentation/virtual/kvm/api.txt fix a typo
    Documentation/early-userspace/README fix a typo
    Documentation/video4linux/soc-camera.txt fix a typo
    lguest: fix CONFIG_PAE -> CONFIG_x86_PAE in comment
    ...

    Linus Torvalds
     

04 Jul, 2013

1 commit

  • Signed-off-by: Zhang Yanfei
    Cc: Vivek Goyal
    Cc: "Eric W. Biederman"
    Cc: "H. Peter Anvin"
    Cc: Benjamin Herrenschmidt
    Cc: Dave Hansen
    Cc: Fenghua Yu
    Cc: Heiko Carstens
    Cc: Martin Schwidefsky
    Cc: Matt Fleming
    Cc: Michael Holzheu
    Cc: Paul Mackerras
    Cc: Ralf Baechle
    Cc: Tony Luck
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Zhang Yanfei
     

28 May, 2013

1 commit


03 Apr, 2013

1 commit

  • 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:
    [] show_stack+0x80/0xa0
    sp=e000000021e8fbd0 bsp=e000000021e81360
    [] dump_stack+0x30/0x50
    sp=e000000021e8fda0 bsp=e000000021e81348
    [] bad_page+0x280/0x380
    sp=e000000021e8fda0 bsp=e000000021e81308
    [] free_hot_cold_page+0x3a0/0x5c0
    sp=e000000021e8fda0 bsp=e000000021e812a0
    [] free_hot_page+0x30/0x60
    sp=e000000021e8fda0 bsp=e000000021e81280
    [] __free_pages+0xb0/0xe0
    sp=e000000021e8fda0 bsp=e000000021e81258
    [] free_pages+0xa0/0xc0
    sp=e000000021e8fda0 bsp=e000000021e81230
    [] free_initrd_mem+0x230/0x290
    sp=e000000021e8fda0 bsp=e000000021e811d8
    [] populate_rootfs+0x1c0/0x280
    sp=e000000021e8fdb0 bsp=e000000021e811a0
    [] do_one_initcall+0x3b0/0x3e0
    sp=e000000021e8fdb0 bsp=e000000021e81158
    [] kernel_init+0x3f0/0x4b0
    sp=e000000021e8fdb0 bsp=e000000021e81108
    [] kernel_thread_helper+0xd0/0x100
    sp=e000000021e8fe30 bsp=e000000021e810e0
    [] 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: Xishi Qiu
    Signed-off-by: Tony Luck

    Xishi Qiu
     

19 Jul, 2012

1 commit


27 Dec, 2011

1 commit


25 Nov, 2010

1 commit


13 Jun, 2009

1 commit


22 Oct, 2008

1 commit

  • 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: Paul Mackerras
    Signed-off-by: Mohan Kumar M
    Signed-off-by: Michael Ellerman
    Signed-off-by: Benjamin Herrenschmidt

    Mohan Kumar M
     

29 Jul, 2008

1 commit


08 Jul, 2008

1 commit


01 May, 2008

1 commit

  • The extended crashkernel syntax is a little confusing in the way it handles
    ranges. eg:

    crashkernel=512M-2G:64M,2G-:128M

    Means if the machine has between 512M and 2G of memory the crash region should
    be 64M, and if the machine has 2G of memory the region should be 64M. Only if
    the machine has more than 2G memory will 128M be allocated.

    Although that semantic is correct, it is somewhat baffling. Instead I propose
    that the end of the range means the first address past the end of the range,
    ie: 512M up to but not including 2G.

    [bwalle@suse.de: clarify inclusive/exclusive in crashkernel commandline in documentation]
    Signed-off-by: Michael Ellerman
    Acked-by: Bernhard Walle
    Cc: "Eric W. Biederman"
    Cc: Simon Horman
    Signed-off-by: Bernhard Walle
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael Ellerman
     

20 Oct, 2007

1 commit

  • This adds the documentation for the extended crashkernel syntax into
    Documentation/kdump/kdump.txt.

    Signed-off-by: Bernhard Walle
    Cc: Andi Kleen
    Cc: "Luck, Tony"
    Cc: Paul Mackerras
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mundt
    Cc: Vivek Goyal
    Cc: "Eric W. Biederman"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bernhard Walle
     

17 Oct, 2007

4 commits

  • This cleans up kdump documentation a bit. Plus I do not think we want
    to mention Linux trademark in _every_ file in documentation....

    Signed-off-by: Pavel Machek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pavel Machek
     
  • This patch adds the "reset_devices" option (that's used only by one device
    driver for now) to the recommended list of command line parameters for kdump.

    Meaning (Documentation/kernel-parameters.txt):
    reset_devices [KNL] Force drivers to reset the underlying device
    during initialization.

    Signed-off-by: Bernhard Walle
    Cc: "Randy.Dunlap"
    Cc: Vivek Goyal
    Cc: "Eric W. Biederman"
    Cc: Haren Myneni
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bernhard Walle
     
  • This patch reflects the
    http://git.kernel.org/?p=linux/kernel/git/horms/kexec-tools-testing.git;a=commit;h=b9c3648e690ad0dad12389659673206213a09760
    change in kexec-tools-testing also now in the kernel documentation.

    Signed-off-by: Bernhard Walle
    Cc: "Randy.Dunlap"
    Cc: Vivek Goyal
    Cc: "Eric W. Biederman"
    Cc: Haren Myneni
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bernhard Walle
     
  • This patch adapts the Documentation/kdump/kdump.txt file to express the fact
    that the x86_64 kernel is now also relocatable. This makes i386 and x86_64
    now behave the same, simplifying the documentation.

    Signed-off-by: Bernhard Walle
    Cc: "Randy.Dunlap"
    Cc: Vivek Goyal
    Cc: "Eric W. Biederman"
    Cc: Haren Myneni
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bernhard Walle
     

21 Feb, 2007

1 commit

  • Patch from Mohan Kumar M to add the ppc64 portions of the kdump
    documentation.

    http://thread.gmane.org/gmane.linux.kernel/481689/focus=3375

    Cc: Mohan Kumar M
    Cc: Vivek Goyal
    Signed-off-by: Simon Horman
    Cc: Paul Mackerras
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Simon Horman
     

13 Feb, 2007

1 commit

  • I've noticed that the boot options are not correct for in the documentation
    for kdump. The "init" keyword is not necessary, and causes a kernel panic
    when booting with an initrd on Fedora 5.

    [horms@verge.net.au: put original comment with the latest version of the patch]
    Signed-off-by: Judith Lebzeelter
    Acked-by: Vivek Goyal
    Signed-off-by: Simon Horman
    Cc: "Eric W. Biederman"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Horms
     

23 Jan, 2007

2 commits


12 Jan, 2007

1 commit

  • o Kdump documentation update.
    - Update details for using relocatable kernel.
    - Start using kexec-tools-testing release as it is latest and old
    kexec-tools can't load relocatable bzImage file.
    - Also add kdump on ia64 specific details.

    Signed-off-by: Vivek Goyal
    Cc: Horms
    Cc: Mohan Kumar M
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Vivek Goyal
     

04 Oct, 2006

1 commit


27 Jun, 2006

1 commit

  • In a testament to the utter simplicity and logic of the English
    language ;-), I found a single correct use - in kernel/panic.c - and
    10-15 incorrect ones.

    Signed-Off-By: Lee Revell
    Signed-off-by: Adrian Bunk

    Lee Revell
     

26 Jun, 2006

1 commit


12 Jan, 2006

1 commit


11 Jan, 2006

1 commit


13 Sep, 2005

1 commit


10 Sep, 2005

1 commit

  • There are minor changes in command line options in kexec-tools for kdump.
    This patch updates the documentation to reflect those changes.

    Signed-off-by: Vivek Goyal
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Vivek Goyal
     

26 Jun, 2005

2 commits

  • 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: Vivek Goyal
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Vivek Goyal
     
  • 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 --crash-dump --args-linux --append="root=
    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: Hariprasad Nellitheertha
    Signed-off-by: Eric Biederman
    Signed-off-by: Vivek Goyal
    Signed-off-by: randy_dunlap
    Signed-off-by: Maneesh Soni
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Vivek Goyal