ubuntu@grotrian:~$ cat /proc/version
Linux version 4.10.0-28-generic (buildd@bos01-arm64-012) (gcc version 6.3.0 
20170406 (Ubuntu/Linaro 6.3.0-12ubuntu2) ) #32-Ubuntu SMP Fri Jun 30 05:33:10 
UTC 2017
ubuntu@grotrian:~$ cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-4.10.0-28-generic 
root=UUID=fcf02e40-f2bd-4c9f-a9bd-1abe132cbc9e ro acpi=on crashkernel=1G-:512M
ubuntu@grotrian:~$ echo c | sudo tee /proc/sysrq-trigger 
c

<crash/reboot>

ubuntu@grotrian:~$ sudo crash
/usr/lib/debug/boot/vmlinux-4.10.0-28-generic
/var/crash/201707102147/dump.201707102147

crash 7.1.8
Copyright (C) 2002-2016  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.
 
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "aarch64-unknown-linux-gnu"...

      KERNEL: /usr/lib/debug/boot/vmlinux-4.10.0-28-generic
    DUMPFILE: /var/crash/201707102147/dump.201707102147  [PARTIAL DUMP]
        CPUS: 48
        DATE: Mon Jul 10 21:47:34 2017
      UPTIME: 00:35:42
LOAD AVERAGE: 0.13, 0.31, 0.26
       TASKS: 578
    NODENAME: grotrian
     RELEASE: 4.10.0-28-generic
     VERSION: #32-Ubuntu SMP Fri Jun 30 05:33:10 UTC 2017
     MACHINE: aarch64  (unknown Mhz)
      MEMORY: 128 GB
       PANIC: "sysrq: SysRq : Trigger a crash"
         PID: 5136
     COMMAND: "tee"
        TASK: ffff801f4682ba00  [THREAD_INFO: ffff801f4682ba00]
         CPU: 45
       STATE: TASK_RUNNING (SYSRQ)

crash> bt
PID: 5136   TASK: ffff801f4682ba00  CPU: 45  COMMAND: "tee"
 #0 [ffff801f48e8ba40] crash_kexec at ffff00000816ce94
 #1 [ffff801f48e8ba70] die at ffff00000808b23c
 #2 [ffff801f48e8bab0] do_page_fault at ffff000008a099e4
 #3 [ffff801f48e8bb20] do_translation_fault at ffff000008a09cb8
 #4 [ffff801f48e8bb50] do_mem_abort at ffff000008081490
 #5 [ffff801f48e8bd50] el1_ia at ffff000008082f28
     PC: ffff00000863ffcc  [sysrq_handle_crash+36]
     LR: ffff000008640c54  [__handle_sysrq+292]
     SP: ffff801f48e8bd50  PSTATE: 00400145
    X29: ffff801f48e8bd50  X28: ffff801f4682ba00  X27: ffff000008a22000
    X26: 0000000000000040  X25: 0000000000000123  X24: 0000000000000015
    X23: 0000000000000000  X22: 0000000000000004  X21: ffff0000092a9500
    X20: 0000000000000063  X19: ffff000009231000  X18: ffffffffffffffff
    X17: 0000ffff796f43d0  X16: ffff00000829e9a8  X15: ffff000009208b10
    X14: ffff00008935c7bf  X13: ffff00000935c7cd  X12: 7565726f632f5345
    X11: ffff000009231000  X10: 0000000005f5e0ff   X9: 00000000ffffffd0
     X8: ffff0000086676b0   X7: 6767697254203a20   X6: 00000000000004fb
     X5: 0000000000000000   X4: 0000000000000000   X3: 0000000000000000
     X2: 0000000000040a11   X1: 0000000000000000   X0: 0000000000000001
 #6 [ffff801f48e8bd60] __handle_sysrq at ffff000008640c50
 #7 [ffff801f48e8bda0] write_sysrq_trigger at ffff000008641108
 #8 [ffff801f48e8bdc0] proc_reg_write at ffff00000831ec84
 #9 [ffff801f48e8be00] __vfs_write at ffff00000829beac
#10 [ffff801f48e8be30] vfs_write at ffff00000829d3c8
#11 [ffff801f48e8be70] sys_write at ffff00000829ea10
#12 [ffff801f48e8bed0] el0_svc_naked at ffff0000080838ec
     PC: 0000000000000003   LR: 0000ffff79745cb8   SP: 0000000020000000
    X29: 0000ffffd17124b0  X28: 0000ffff796f5498  X27: 0000ffffd17124b0
    X26: 0000000000000001  X25: 000000002d76dbf0  X24: 0000000000417000
    X23: 0000000000000002  X22: 0000000000000002  X21: 0000ffff797c9638
    X20: 0000000000000002  X19: 000000002d76dbf0  X18: 0000ffffd1712638
    X17: 0000000000000002  X16: 0000000000040a11  X15: 0000ffff796f43d0
    X14: 0000000000000000  X13: 00000000000007fe  X12: 0000000000000018
    X11: 0000000000000000  X10: 7565726f632f5345   X9: 0000000000000000
     X8: 0101010101010101   X7: 000000002d76d050   X6: 0000000000000040
     X5: 0000000000000240   X4: 000000000040582e   X3: 00000000fbad2c87
     X2: 00000000ffffffff   X1: 0000000000000000   X0: 0000000000000002
    ORIG_X0: 0000000000000000  SYSCALLNO: 0  PSTATE: 00000040
crash>

** Tags removed: verification-needed-zesty
** Tags added: verification-done-zesty

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1694859

Title:
  arm64 kernel crashdump support

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Committed
Status in makedumpfile package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  In Progress
Status in linux source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Xenial:
  Confirmed
Status in kexec-tools source package in Yakkety:
  In Progress
Status in linux source package in Yakkety:
  Won't Fix
Status in makedumpfile source package in Yakkety:
  Confirmed
Status in kexec-tools source package in Zesty:
  In Progress
Status in linux source package in Zesty:
  Fix Committed
Status in makedumpfile source package in Zesty:
  Confirmed

Bug description:
  Note: Updates are being staged at ppa:dannf/arm64-kdump.

  [Impact]
  It is not possible to collect a kernel crash dump from a crashed arm64 server 
for later debugging.

  [Test Case]
  sudo apt install kdump-tools
  (reboot, so crashkernel= is added to the kernel commandline)
  echo c | sudo tee /proc/sysrq-trigger

  Crash dump should occur, with artifacts collected in /var/crash.

  If you want to verify that the dump is usable, install the
  corresponding linux-image-<ver>-dbgsym package and run:

  sudo crash /usr/lib/debug/boot/vmlinux-<ver>
  /var/crash/<crash>/dump.<crash>

  crash should successfully load, placing you at a "crash>" prompt. At that 
prompt, you can issue the 'bt' command to see a backtrace.
  Note: you need crash from zesty (7.1.8-1ubuntu1) or later.

  [Regression Risk]
  = Kernel =
  3 patches here touch code outside of arch/arm64/:

  memblock: add memblock_clear_nomap()
  This adds a new function with no callers, so regression risk is negligible.
  (A later patch adds a call to it under arch/arm64/).

  memblock: add memblock_cap_memory_range()
  This refactors some of the code in memblock_mem_limit_remove_map() into a new 
function. The only existing caller of memblock_mem_limit_remove_map() is under 
arch/arm64/, so the regression risk outside of arm64 is negligible.

  efi/libstub/arm*: Set default address and size cells values for an empty dtb
  Because this code is for EFI platforms that support device-tree, it is 
de-facto ARM-specific (as noted in the patch title).

  For arm64, we have mitigated the risk by explicit regression testing on 
several platforms:
   - Qualcomm QDF2400
   - Cavium ThunderX CRB1S
   - HP m400 (X-Gene)
   - HiSilicon D05 (Hi07)

  = kexec-tools =
  == zesty ==
  For zesty, 10 patches are required to add kdump support.

  0001-kexec-extend-the-semantics-of-kexec_iomem_for_each_l.patch:
  This modifies a function used on armhf & x86. The description explains the 
change, and why it does not impact those archs:

  -----
  The current users of kexec_iomem_for_each_line(), arm, sh and x86, will not
  be affected by this change because
  * arm
    The callback function only returns -1 or 0, and the return value of
    kexec_iomem_for_each_line() will never be used.
  * sh, x86
    The callback function may return (-1 for sh,) 0 or 1, but always returns
    1 once we have reached the maximum number of entries allowed.
    Even so the current kexec_iomem_for_each_line() counts them up.
    This change actually fixes this bug.
  -----

  0002-kexec-generalize-and-rename-get_kernel_stext_sym.patch:
  This generalizes a function that was duplicated by arm & x86 and makes it 
common so arm64 can use it.

  The remaining 8 of these only touch code in kexec/arch/arm64, so
  regression risk for other architectures is negligible.

  Finally, I have tested this update on both i386 and amd64 VMs. i386
  crashes do not currently work in zesty (filed LP: #1699874), and my
  test results show no change there. amd64 worked before, and continues
  to work with these changes.

  == yakkety ==
  Since yakkety is based on an older upstream, 6 additional patches are 
required:

  arm-fix-get_kernel_stext_sym-to-close-its-file.patch:
  This is a cleanup patch, cherry-picked because it allows later patches to 
apply w/o backporting. ARM-specific.

  kexec-add-max_size-to-memory_ranges.patch:
  Adds a new element to struct, to be used by later commits.

  kexec-add-generic-helper-to-add-to-memoryq_regions.patch,
  kexec-add-mem_regions-sorting-implementation.patch,
  kexec-add-helper-to-exlude-a-region-from-a-set-of-me.patch,
  kexec-fix-mem_regions_sort.patch:
  These patches only add new functions, which will be used by later patches.

  kexec-arch-i386-Add-support-for-KASLR-memory-randomi.patch:
  This is a bug fix or i386 that allows later patches to apply w/o backporting.
  kdump support for i386 is apparently broken for the yakkety kernel (see LP: 
#1699874) so, if this introduces a regression, it won't be detectable.
  (I checked to see if this *fixes* i386 crashdumps - it does not).

  Note that, while makedumpfile in >= zesty is new enough to work on arm64, the 
yakkety version does not. kdump-tools falls back to copying the entire vmcore, 
which is what I tested.
  As with zesty, I have tested this update on both i386 and amd64 VMs. i386 
crashes do not currently work in yakkety, and my test results show no change 
there. amd64 worked before, and continues to work with these changes.

  = xenial =
  The patchset needed for xenial is identical to the patchset for yakkety. The 
only additional change is to add arm64 to the list of archs that get a 
/etc/default/grub.d snippet (in yakkety that snippet moved over to 
kdump-tools), and that has negligible regression risk for !arm64.

  I performed the same testing as with yakkety. The only significant
  difference is that i386 worked before and after this update (for y/z/a
  it worked neither before nor after).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1694859/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to