[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

** Changed in: makedumpfile (Ubuntu Artful)
   Status: In Progress => Fix Released

-- 
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 Released
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  Fix Released
Status in linux source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Xenial:
  Fix Released
Status in kexec-tools source package in Yakkety:
  Won't Fix
Status in linux source package in Yakkety:
  Won't Fix
Status in makedumpfile source package in Yakkety:
  Won't Fix
Status in kexec-tools source package in Zesty:
  Fix Released
Status in linux source package in Zesty:
  Fix Released
Status in makedumpfile source package in Zesty:
  Fix Released
Status in kexec-tools source package in Artful:
  Fix Released
Status in linux source package in Artful:
  Fix Released
Status in makedumpfile source package in Artful:
  Fix Released
Status in makedumpfile package in Debian:
  Fix Released

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--dbgsym package and run:

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

  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.

  

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[Bug Watch Updater]

** Changed in: makedumpfile (Debian)
   Status: Unknown => Fix Released

-- 
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 Released
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  Fix Released
Status in linux source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Xenial:
  Fix Released
Status in kexec-tools source package in Yakkety:
  Won't Fix
Status in linux source package in Yakkety:
  Won't Fix
Status in makedumpfile source package in Yakkety:
  Won't Fix
Status in kexec-tools source package in Zesty:
  Fix Released
Status in linux source package in Zesty:
  Fix Released
Status in makedumpfile source package in Zesty:
  Fix Released
Status in kexec-tools source package in Artful:
  Fix Released
Status in linux source package in Artful:
  Fix Released
Status in makedumpfile source package in Artful:
  In Progress
Status in makedumpfile package in Debian:
  Fix Released

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--dbgsym package and run:

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

  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.

  

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

** Bug watch added: Debian Bug tracker #883899
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883899

** Also affects: makedumpfile (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883899
   Importance: Unknown
   Status: Unknown

** Changed in: linux (Ubuntu Artful)
   Status: New => Fix Released

** Changed in: makedumpfile (Ubuntu Artful)
   Status: New => In Progress

** Changed in: makedumpfile (Ubuntu Artful)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: kexec-tools (Ubuntu Artful)
   Status: New => Fix Released

-- 
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 Released
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  Fix Released
Status in linux source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Xenial:
  Fix Released
Status in kexec-tools source package in Yakkety:
  Won't Fix
Status in linux source package in Yakkety:
  Won't Fix
Status in makedumpfile source package in Yakkety:
  Won't Fix
Status in kexec-tools source package in Zesty:
  Fix Released
Status in linux source package in Zesty:
  Fix Released
Status in makedumpfile source package in Zesty:
  Fix Released
Status in kexec-tools source package in Artful:
  Fix Released
Status in linux source package in Artful:
  Fix Released
Status in makedumpfile source package in Artful:
  In Progress
Status in makedumpfile package in Debian:
  Unknown

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--dbgsym package and run:

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

  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, 

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

** Also affects: kexec-tools (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Also affects: makedumpfile (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Changed in: kexec-tools (Ubuntu Yakkety)
   Status: In Progress => Won't Fix

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile 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 Released
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  Fix Released
Status in linux source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Xenial:
  Fix Released
Status in kexec-tools source package in Yakkety:
  Won't Fix
Status in linux source package in Yakkety:
  Won't Fix
Status in makedumpfile source package in Yakkety:
  Won't Fix
Status in kexec-tools source package in Zesty:
  Fix Released
Status in linux source package in Zesty:
  Fix Released
Status in makedumpfile source package in Zesty:
  Fix Released
Status in kexec-tools source package in Artful:
  Fix Released
Status in linux source package in Artful:
  Fix Released
Status in makedumpfile source package in Artful:
  In Progress
Status in makedumpfile package in Debian:
  Unknown

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--dbgsym package and run:

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

  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.

  

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[Launchpad Bug Tracker]

This bug was fixed in the package makedumpfile - 1:1.5.9-5ubuntu0.5

---
makedumpfile (1:1.5.9-5ubuntu0.5) xenial; urgency=medium

  * Build on arm64. While this version of makedumpfile doesn't support
creating filtered dumps of Ubuntu arm64 kernels, it does satisfy
the dependency for kdump-tools, which will cleanly fallback to 'cp'
mode if makedumpfile fails. LP: #1238110, LP: #1694859.

 -- dann frazier   Mon, 17 Jul 2017 16:58:59
-0600

** Changed in: makedumpfile (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

-- 
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 Released
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  Fix Released
Status in linux source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Xenial:
  Fix Released
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:
  Won't Fix
Status in kexec-tools source package in Zesty:
  Fix Released
Status in linux source package in Zesty:
  Fix Released
Status in makedumpfile source package in Zesty:
  Fix Released

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--dbgsym package and run:

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

  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.

  

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[Launchpad Bug Tracker]

This bug was fixed in the package kexec-tools - 1:2.0.14-1ubuntu3.1

---
kexec-tools (1:2.0.14-1ubuntu3.1) zesty; urgency=medium

  * Add backport of upstream arm64 crashdump support (LP: #1694859).

 -- dann frazier   Wed, 21 Jun 2017 15:15:25 -0600

** Changed in: kexec-tools (Ubuntu Zesty)
   Status: Fix Committed => Fix Released

-- 
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 Released
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  Fix Released
Status in linux source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Xenial:
  Fix Committed
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:
  Won't Fix
Status in kexec-tools source package in Zesty:
  Fix Released
Status in linux source package in Zesty:
  Fix Released
Status in makedumpfile source package in Zesty:
  Fix Released

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--dbgsym package and run:

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

  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 

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[Launchpad Bug Tracker]

This bug was fixed in the package kexec-tools - 1:2.0.10-1ubuntu2.3

---
kexec-tools (1:2.0.10-1ubuntu2.3) xenial; urgency=medium

  * Add backport of upstream arm64 crashdump support (LP: #1694859).

 -- dann frazier   Fri, 23 Jun 2017 12:27:52
-0600

** Changed in: kexec-tools (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

-- 
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 Released
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  Fix Released
Status in linux source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Xenial:
  Fix Committed
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:
  Won't Fix
Status in kexec-tools source package in Zesty:
  Fix Released
Status in linux source package in Zesty:
  Fix Released
Status in makedumpfile source package in Zesty:
  Fix Released

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--dbgsym package and run:

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

  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, 

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

dannf@d05-3:~$ sudo apt install kdump-tools
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  crash kexec-tools makedumpfile
The following NEW packages will be installed:
  crash kdump-tools kexec-tools makedumpfile
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 2,291 kB of archives.
After this operation, 7,092 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://us.ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 crash 
arm64 7.1.4-1ubuntu4.1 [2,096 kB]
Get:2 http://us.ports.ubuntu.com/ubuntu-ports xenial-proposed/main arm64 
makedumpfile arm64 1:1.5.9-5ubuntu0.5 [111 kB]
Get:3 http://us.ports.ubuntu.com/ubuntu-ports xenial-proposed/main arm64 
kexec-tools arm64 1:2.0.10-1ubuntu2.3 [63.3 kB]
Get:4 http://us.ports.ubuntu.com/ubuntu-ports xenial-proposed/main arm64 
kdump-tools all 1:1.5.9-5ubuntu0.5 [20.9 kB]
Fetched 2,291 kB in 0s (21.4 MB/s)  
Preconfiguring packages ...
Selecting previously unselected package crash.
(Reading database ... 93733 files and directories currently installed.)
Preparing to unpack .../crash_7.1.4-1ubuntu4.1_arm64.deb ...
Unpacking crash (7.1.4-1ubuntu4.1) ...
Selecting previously unselected package makedumpfile.
Preparing to unpack .../makedumpfile_1%3a1.5.9-5ubuntu0.5_arm64.deb ...
Unpacking makedumpfile (1:1.5.9-5ubuntu0.5) ...
Selecting previously unselected package kexec-tools.
Preparing to unpack .../kexec-tools_1%3a2.0.10-1ubuntu2.3_arm64.deb ...
Unpacking kexec-tools (1:2.0.10-1ubuntu2.3) ...
Selecting previously unselected package kdump-tools.
Preparing to unpack .../kdump-tools_1%3a1.5.9-5ubuntu0.5_all.deb ...
Unpacking kdump-tools (1:1.5.9-5ubuntu0.5) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for systemd (229-4ubuntu19) ...
Processing triggers for ureadahead (0.100.0-19) ...
ureadahead will be reprofiled on next reboot
Setting up crash (7.1.4-1ubuntu4.1) ...
Setting up makedumpfile (1:1.5.9-5ubuntu0.5) ...
Setting up kexec-tools (1:2.0.10-1ubuntu2.3) ...
Generating /etc/default/kexec...
Generating grub configuration file ...
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 23506: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 23506: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 23555: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 23555: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 23598: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 23598: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 23675: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 23675: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 23823: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 23823: 
/usr/sbin/grub-probe
Found linux image: /boot/vmlinuz-4.10.0-27-generic
Found initrd image: /boot/initrd.img-4.10.0-27-generic
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 24161: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 24161: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[70529]) leaked on lvs invocation. Parent PID 24390: 
/bin/sh
Found Ubuntu 17.04 (17.04) on /dev/sda2
Adding boot menu entry for EFI firmware configuration
done
Setting up kdump-tools (1:1.5.9-5ubuntu0.5) ...
Processing triggers for systemd (229-4ubuntu19) ...
Processing triggers for ureadahead (0.100.0-19) ...
dannf@d05-3:~$

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

-- 
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 Released
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  Fix Committed
Status in linux source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Xenial:
  Fix Committed
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:
  Won't Fix
Status in kexec-tools source package in Zesty:
  Fix Committed
Status in linux source package in Zesty:
  Fix Released
Status in makedumpfile source package in Zesty:
  Fix Released

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

  [Impact]
  It is not possible 

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[Brian Murray]

Hello dann, or anyone else affected,

Accepted makedumpfile into xenial-proposed. The package will build now
and be available at
https://launchpad.net/ubuntu/+source/makedumpfile/1:1.5.9-5ubuntu0.5 in
a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-xenial to verification-done-xenial. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-xenial. In either case, details of your
testing will help us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: makedumpfile (Ubuntu)
   Status: Confirmed => Fix Released

** Changed in: makedumpfile (Ubuntu Zesty)
   Status: Confirmed => Fix Released

** Changed in: makedumpfile (Ubuntu Yakkety)
   Status: Confirmed => Won't Fix

** Changed in: makedumpfile (Ubuntu Xenial)
   Status: Confirmed => Fix Committed

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

-- 
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 Released
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  Fix Committed
Status in linux source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Xenial:
  Fix Committed
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:
  Won't Fix
Status in kexec-tools source package in Zesty:
  Fix Committed
Status in linux source package in Zesty:
  Fix Released
Status in makedumpfile source package in Zesty:
  Fix Released

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--dbgsym package and run:

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

  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.
  -

  

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

kexec-tools/xenial verification
---
1) MAAS-deployed a clean xenial install
2) Added -proposed to sources.list
3) xenial linux-hwe doesn't yet have arm64/kdump support, so I installed
   linux-hwe from ppa:canonical-kernel-team/ppa to get a new enough version.
4) Also installed linux-image-4.10.0-28-generic-dbgsym from CKT PPA.
5) Installed a manually built makedumpfile deb to fulfill a dependency for 
kdump-tools
   The only change is adding 'arm64' to the Architecture list in debian/control
   (Resolving that is another bug task here).
6) Installed crash deb from zesty - xenial's crash is too old to support 4.10 
on arm64.
7) apt update; apt dist-upgrade; apt install kdump-tools
4) Edited /etc/default/grub.d/kdump-tools.cfg and set crashkernel=1G-:512M
   (this step is required until defaults are updated via kdump-tools)
5) Rebooted for changes to take effect.
6) Noticed that kdump-tools failed to load due to a broken symlink;
   ran 'dpkg-reconfigure kdump-tools' to fix
7) Ran the test case in this bug's description. Test log attached.

** Attachment added: "kexec-tools-xenial-verification.log"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1694859/+attachment/4916441/+files/kexec-tools-xenial-verification.log

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

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

-- 
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 Released
Status in makedumpfile package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Fix Committed
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:
  Fix Committed
Status in linux source package in Zesty:
  Fix Released
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--dbgsym package and run:

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

  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 

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

kexec-tools/zesty verification
---
1) MAAS-deployed a clean zesty install
2) Added -proposed to sources.list
3) apt update; apt dist-upgrade; apt install kdump-tools
4) Edited /etc/default/grub.d/kdump-tools.cfg and set crashkernel=1G-:512M
   (this step is required until defaults are updated via kdump-tools)
5) Rebooted for changes to take effect.
6) Noticed that kdump-tools failed to load due to a broken symlink;
   ran 'dpkg-reconfigure kdump-tools' to fix
7) Added ddebs.ubuntu.com to sources.list & installed apt key for it
8) apt install linux-image-$(uname -r)-dbgsym

Test log attached.

** Attachment added: "kexec-tools-zesty-verification.log"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1694859/+attachment/4916402/+files/kexec-tools-zesty-verification.log

** 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 Released
Status in makedumpfile package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Fix Committed
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:
  Fix Committed
Status in linux source package in Zesty:
  Fix Released
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--dbgsym package and run:

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

  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:

  

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[Launchpad Bug Tracker]

This bug was fixed in the package linux - 4.10.0-28.32

---
linux (4.10.0-28.32) zesty; urgency=low

  * linux: 4.10.0-28.32 -proposed tracker (LP: #1701013)

  * KILLER1435-S[0489:e0a2] BT cannot search BT 4.0 device (LP: #1699651)
- Bluetooth: btusb: Add support for 0489:e0a2 QCA_ROME device

  * aacraid driver may return uninitialized stack data to userspace
(LP: #1700077)
- SAUCE: scsi: aacraid: Don't copy uninitialized stack memory to userspace

  * CVE-2017-9605
- drm/vmwgfx: Make sure backup_handle is always valid

  * CVE-2017-1000380
- ALSA: timer: Fix race between read and ioctl
- ALSA: timer: Fix missing queue indices reset at SNDRV_TIMER_IOCTL_SELECT

  * XDP eBPF programs fail to verify on Zesty ppc64el (LP: #1699627)
- [Config] ppc64el: build for Power8 not Power7

  * AACRAID for power9 platform (LP: #1689980)
- scripts/spelling.txt: add "therfore" pattern and fix typo instances
- scsi: aacraid: fix PCI error recovery path
- scsi: aacraid: pci_alloc_consistent() failures on ARM64
- scsi: aacraid: Remove __GFP_DMA for raw srb memory
- scsi: aacraid: Fix DMAR issues with iommu=pt
- scsi: aacraid: Added 32 and 64 queue depth for arc natives
- scsi: aacraid: Set correct Queue Depth for HBA1000 RAW disks
- scsi: aacraid: Remove reset support from check_health
- scsi: aacraid: Change wait time for fib completion
- scsi: aacraid: Log count info of scsi cmds before reset
- scsi: aacraid: Print ctrl status before eh reset
- scsi: aacraid: Using single reset mask for IOP reset
- scsi: aacraid: Rework IOP reset
- scsi: aacraid: Add periodic checks to see IOP reset status
- scsi: aacraid: Rework SOFT reset code
- scsi: aacraid: Rework aac_src_restart
- scsi: aacraid: Use correct function to get ctrl health
- scsi: aacraid: Make sure ioctl returns on controller reset
- scsi: aacraid: Enable ctrl reset for both hba and arc
- scsi: aacraid: Add reset debugging statements
- scsi: aacraid: Remove reference to Series-9
- scsi: aacraid: Update driver version to 50834

  * arm64 kernel crashdump support (LP: #1694859)
- memblock: add memblock_clear_nomap()
- memblock: add memblock_cap_memory_range()
- arm64: limit memory regions based on DT property, usable-memory-range
- arm64: kdump: reserve memory for crash dump kernel
- arm64: mm: add set_memory_valid()
- arm64: mm: use phys_addr_t instead of unsigned long in __map_memblock
- arm64: kdump: protect crash dump kernel memory
- arm64: hibernate: preserve kdump image around hibernation
- arm64: kdump: implement machine_crash_shutdown()
- arm64: kdump: add VMCOREINFO's for user-space tools
- [Config] CONFIG_CRASH_DUMP=y on arm64
- arm64: kdump: provide /proc/vmcore file
- Documentation: kdump: describe arm64 port
- Documentation: dt: chosen properties for arm64 kdump
- efi/libstub/arm*: Set default address and size cells values for an empty 
dtb

  * hibmc driver does not include "pci:" prefix in bus ID (LP: #1698700)
- SAUCE: drm: hibmc: Use set_busid function from drm core

  * Processes in "D" state due to zap_pid_ns_processes kernel call with Ubuntu +
Docker (LP: #1698264)
- pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes

  * Bugfixes for  hns network driver (LP: #1696031)
- hns_enet: use cpumask_var_t for on-stack mask
- net: hns: fix uninitialized data use
- net: hns: avoid gcc-7.0.1 warning for uninitialized data
- net: hns: Add ACPI support to check SFP present
- net: hns: Fix the implementation of irq affinity function
- net: hns: Modify GMAC init TX threshold value
- net: hns: Optimize the code for GMAC pad and crc Config
- net: hns: Remove redundant memset during buffer release
- net: hns: bug fix of ethtool show the speed
- net: hns: Optimize hns_nic_common_poll for better performance
- net: hns: Fix to adjust buf_size of ring according to mtu
- net: hns: Replace netif_tx_lock to ring spin lock
- net: hns: Correct HNS RSS key set function
- net: hns: Remove the redundant adding and deleting mac function
- net: hns: Remove redundant mac_get_id()
- net: hns: Remove redundant mac table operations
- net: hns: Clean redundant code from hns_mdio.c file
- net: hns: Optimise the code in hns_mdio_wait_ready()
- net: hns: Simplify the exception sequence in hns_ppe_init()
- net: hns: Adjust the SBM module buffer threshold
- net: hns: Avoid Hip06 chip TX packet line bug
- net: hns: Some checkpatch.pl script & warning fixes
- net: hns: support deferred probe when can not obtain irq
- net: hns: support deferred probe when no mdio
- net: hns: fix ethtool_get_strings overflow in hns driver

  * CVE-2017-7346
- drm/vmwgfx: limit the number of mip levels in 
vmw_gb_surface_define_ioctl()

  * [SRU][Zesty] qcom_emac is unable to get ip address with at803x 

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[Brian Murray]

Hello dann, or anyone else affected,

Accepted kexec-tools into xenial-proposed. The package will build now
and be available at https://launchpad.net/ubuntu/+source/kexec-
tools/1:2.0.10-1ubuntu2.3 in a few hours, and then in the -proposed
repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-xenial to verification-done-xenial. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-xenial. In either case, details of your
testing will help us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: kexec-tools (Ubuntu Xenial)
   Status: In Progress => Fix Committed

** Tags added: verification-needed-xenial

-- 
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 Released
Status in makedumpfile package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Fix Committed
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:
  Fix Committed
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--dbgsym package and run:

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

  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 

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[Brian Murray]

Hello dann, or anyone else affected,

Accepted kexec-tools into zesty-proposed. The package will build now and
be available at https://launchpad.net/ubuntu/+source/kexec-
tools/1:2.0.14-1ubuntu3.1 in a few hours, and then in the -proposed
repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-zesty to verification-done-zesty. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-zesty. In either case, details of your testing
will help us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: kexec-tools (Ubuntu Zesty)
   Status: In Progress => Fix Committed

** Tags removed: verification-done-zesty
** Tags added: verification-needed verification-needed-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 Released
Status in makedumpfile package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Fix Committed
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:
  Fix Committed
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--dbgsym package and run:

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

  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 

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[Launchpad Bug Tracker]

This bug was fixed in the package linux - 4.11.0-10.15

---
linux (4.11.0-10.15) artful; urgency=low

  * linux: 4.11.0-10.15 -proposed tracker (LP: #1701271)

  * Artful update to v4.11.8 stable release (LP: #1701269)
- clk: sunxi-ng: a31: Correct lcd1-ch1 clock register offset
- clk: sunxi-ng: v3s: Fix usb otg device reset bit
- clk: sunxi-ng: sun5i: Fix ahb_bist_clk definition
- xen/blkback: fix disconnect while I/Os in flight
- xen-blkback: don't leak stack data via response ring
- ALSA: firewire-lib: Fix stall of process context at packet error
- ALSA: pcm: Don't treat NULL chmap as a fatal error
- ALSA: hda - Add Coffelake PCI ID
- ALSA: hda - Apply quirks to Broxton-T, too
- fs/exec.c: account for argv/envp pointers
- powerpc/perf: Fix oops when kthread execs user process
- autofs: sanity check status reported with AUTOFS_DEV_IOCTL_FAIL
- fs/dax.c: fix inefficiency in dax_writeback_mapping_range()
- lib/cmdline.c: fix get_options() overflow while parsing ranges
- perf/x86/intel: Add 1G DTLB load/store miss support for SKL
- perf probe: Fix probe definition for inlined functions
- KVM: x86: fix singlestepping over syscall
- KVM: MIPS: Fix maybe-uninitialized build failure
- KVM: s390: gaccess: fix real-space designation asce handling for gmap
  shadows
- KVM: PPC: Book3S HV: Cope with host using large decrementer mode
- KVM: PPC: Book3S HV: Preserve userspace HTM state properly
- KVM: PPC: Book3S HV: Ignore timebase offset on POWER9 DD1
- KVM: PPC: Book3S HV: Context-switch EBB registers properly
- KVM: PPC: Book3S HV: Restore critical SPRs to host values on guest exit
- KVM: PPC: Book3S HV: Save/restore host values of debug registers
- CIFS: Improve readdir verbosity
- CIFS: Fix some return values in case of error in 'crypt_message'
- cxgb4: notify uP to route ctrlq compl to rdma rspq
- HID: Add quirk for Dell PIXART OEM mouse
- random: silence compiler warnings and fix race
- signal: Only reschedule timers on signals timers have sent
- powerpc/kprobes: Pause function_graph tracing during jprobes handling
- powerpc/64s: Handle data breakpoints in Radix mode
- Input: i8042 - add Fujitsu Lifebook AH544 to notimeout list
- brcmfmac: add parameter to pass error code in firmware callback
- brcmfmac: use firmware callback upon failure to load
- brcmfmac: unbind all devices upon failure in firmware callback
- time: Fix clock->read(clock) race around clocksource changes
- time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond accounting
- arm64/vdso: Fix nsec handling for CLOCK_MONOTONIC_RAW
- target: Fix kref->refcount underflow in transport_cmd_finish_abort
- iscsi-target: Fix delayed logout processing greater than
  SECONDS_FOR_LOGOUT_COMP
- iscsi-target: Reject immediate data underflow larger than SCSI transfer
  length
- drm/radeon: add a PX quirk for another K53TK variant
- drm/radeon: add a quirk for Toshiba Satellite L20-183
- drm/amdgpu/atom: fix ps allocation size for EnableDispPowerGating
- drm/amdgpu: adjust default display clock
- drm/amdgpu: add Polaris12 DID
- ACPI / scan: Apply default enumeration to devices with ACPI drivers
- ACPI / scan: Fix enumeration for special SPI and I2C devices
- rxrpc: Fix several cases where a padded len isn't checked in ticket decode
- drm: Fix GETCONNECTOR regression
- usb: gadget: f_fs: avoid out of bounds access on comp_desc
- spi: double time out tolerance
- net: phy: fix marvell phy status reading
- brcmfmac: fix uninitialized warning in brcmf_usb_probe_phase2()
- Linux 4.11.8

  * powerpc: Invalidate ERAT on powersave wakeup for POWER9 (LP: #1700521)
- SAUCE: powerpc: Invalidate ERAT on powersave wakeup for POWER9

  * Miscellaneous Ubuntu changes
- d-i: Move qcom-emac from arm64 to shared nic-modules

 -- Seth Forshee   Thu, 29 Jun 2017 08:46:53
-0500

** Changed in: linux (Ubuntu)
   Status: Fix Committed => Fix Released

-- 
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 Released
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 

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

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



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 
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: 801f4682ba00  [THREAD_INFO: 801f4682ba00]
 CPU: 45
   STATE: TASK_RUNNING (SYSRQ)

crash> bt
PID: 5136   TASK: 801f4682ba00  CPU: 45  COMMAND: "tee"
 #0 [801f48e8ba40] crash_kexec at 0816ce94
 #1 [801f48e8ba70] die at 0808b23c
 #2 [801f48e8bab0] do_page_fault at 08a099e4
 #3 [801f48e8bb20] do_translation_fault at 08a09cb8
 #4 [801f48e8bb50] do_mem_abort at 08081490
 #5 [801f48e8bd50] el1_ia at 08082f28
 PC: 0863ffcc  [sysrq_handle_crash+36]
 LR: 08640c54  [__handle_sysrq+292]
 SP: 801f48e8bd50  PSTATE: 00400145
X29: 801f48e8bd50  X28: 801f4682ba00  X27: 08a22000
X26: 0040  X25: 0123  X24: 0015
X23:   X22: 0004  X21: 092a9500
X20: 0063  X19: 09231000  X18: 
X17: 796f43d0  X16: 0829e9a8  X15: 09208b10
X14: 8935c7bf  X13: 0935c7cd  X12: 7565726f632f5345
X11: 09231000  X10: 05f5e0ff   X9: ffd0
 X8: 086676b0   X7: 6767697254203a20   X6: 04fb
 X5:    X4:    X3: 
 X2: 00040a11   X1:    X0: 0001
 #6 [801f48e8bd60] __handle_sysrq at 08640c50
 #7 [801f48e8bda0] write_sysrq_trigger at 08641108
 #8 [801f48e8bdc0] proc_reg_write at 0831ec84
 #9 [801f48e8be00] __vfs_write at 0829beac
#10 [801f48e8be30] vfs_write at 0829d3c8
#11 [801f48e8be70] sys_write at 0829ea10
#12 [801f48e8bed0] el0_svc_naked at 080838ec
 PC: 0003   LR: 79745cb8   SP: 2000
X29: d17124b0  X28: 796f5498  X27: d17124b0
X26: 0001  X25: 2d76dbf0  X24: 00417000
X23: 0002  X22: 0002  X21: 797c9638
X20: 0002  X19: 2d76dbf0  X18: d1712638
X17: 0002  X16: 00040a11  X15: 796f43d0
X14:   X13: 07fe  X12: 0018
X11:   X10: 7565726f632f5345   X9: 
 X8: 0101010101010101   X7: 2d76d050   X6: 0040
 X5: 0240   X4: 0040582e   X3: fbad2c87
 X2:    X1:    X0: 0002
ORIG_X0:   SYSCALLNO: 0  PSTATE: 0040
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 

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[Kleber Sacilotto de Souza]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
zesty' to 'verification-done-zesty'. If the problem still exists, change
the tag 'verification-needed-zesty' to 'verification-failed-zesty'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-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--dbgsym package and run:

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

  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.

  

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

** Description changed:

  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--dbgsym package and run:
  
  sudo crash /usr/lib/debug/boot/vmlinux-
  /var/crash//dump.
  
  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.

** Description changed:

  Note: Updates are being staged at ppa:dannf/arm64-kdump.
  
  [Impact]
  It is not possible to collect a 

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

** Description changed:

  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--dbgsym package and run:
  
  sudo crash /usr/lib/debug/boot/vmlinux-
  /var/crash//dump.
  
- crash should successfully load, placing you at a "crash>" prompt. At
- that prompt, you can issue the 'bt' command to see a backtrace.
+ 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.

-- 
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 

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

** Changed in: kexec-tools (Ubuntu Xenial)
   Status: Confirmed => In Progress

-- 
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--dbgsym package and run:

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

  crash should successfully load, placing you at a "crash>" prompt. At
  that prompt, you can issue the 'bt' command to see a backtrace.

  [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* 

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

** Description changed:

  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--dbgsym package and run:
  
  sudo crash /usr/lib/debug/boot/vmlinux-
  /var/crash//dump.
  
  crash should successfully load, placing you at a "crash>" prompt. At
  that prompt, you can issue the 'bt' command to see a backtrace.
  
  [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.
+   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.
+   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 continue to work
+ 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.

-- 
You received this bug notification because 

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

** Changed in: kexec-tools (Ubuntu Yakkety)
   Status: Confirmed => In Progress

-- 
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:
  Confirmed
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--dbgsym package and run:

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

  crash should successfully load, placing you at a "crash>" prompt. At
  that prompt, you can issue the 'bt' command to see a backtrace.

  [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 =
  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 continue
  to work with these changes.

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

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

** Description changed:

  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--dbgsym package and run:
  
  sudo crash /usr/lib/debug/boot/vmlinux-
  /var/crash//dump.
  
  crash should successfully load, placing you at a "crash>" prompt. At
  that prompt, you can issue the 'bt' command to see a backtrace.
  
  [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 =
- TBD
+ 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 continue to work
+ with these changes.

-- 
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:
  Confirmed
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:
  Confirmed
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--dbgsym package and run:

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

  crash should successfully load, placing you at a "crash>" prompt. At
  that prompt, you can issue the 'bt' command to see a backtrace.

  [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 

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

** Description changed:

  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--dbgsym package and run:
  
  sudo crash /usr/lib/debug/boot/vmlinux-
  /var/crash//dump.
  
  crash should successfully load, placing you at a "crash>" prompt. At
  that prompt, you can issue the 'bt' command to see a backtrace.
  
  [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 =
+ TBD

-- 
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:
  Confirmed
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:
  Confirmed
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--dbgsym package and run:

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

  crash should successfully load, placing you at a "crash>" prompt. At
  that prompt, you can issue the 'bt' command to see a backtrace.

  [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 =
  TBD

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

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

** Changed in: kexec-tools (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: makedumpfile (Ubuntu)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: makedumpfile (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: makedumpfile (Ubuntu Zesty)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: linux (Ubuntu)
   Status: In Progress => Fix Committed

-- 
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:
  Confirmed
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:
  Confirmed
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--dbgsym package and run:

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

  crash should successfully load, placing you at a "crash>" prompt. At
  that prompt, you can issue the 'bt' command to see a backtrace.

  [Regression Risk]
  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)

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

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[Manoj Iyer]

** Tags added: qdf2400

-- 
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:
  In Progress
Status in makedumpfile package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Confirmed
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:
  Confirmed
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--dbgsym package and run:

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

  crash should successfully load, placing you at a "crash>" prompt. At
  that prompt, you can issue the 'bt' command to see a backtrace.

  [Regression Risk]
  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)

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

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[Stefan Bader]

** Changed in: linux (Ubuntu Zesty)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Zesty)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile 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:
  In Progress
Status in makedumpfile package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Confirmed
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:
  Confirmed
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--dbgsym package and run:

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

  crash should successfully load, placing you at a "crash>" prompt. At
  that prompt, you can issue the 'bt' command to see a backtrace.

  [Regression Risk]
  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)

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

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

** Description changed:

  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--dbgsym package and run:
+ 
+ sudo crash /usr/lib/debug/boot/vmlinux-
+ /var/crash//dump.
+ 
+ crash should successfully load, placing you at a "crash>" prompt. At
+ that prompt, you can issue the 'bt' command to see a backtrace.
  
  [Regression Risk]
  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)
+  - Qualcomm QDF2400
+  - Cavium ThunderX CRB1S
+  - HP m400 (X-Gene)
+  - HiSilicon D05 (Hi07)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile 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:
  In Progress
Status in makedumpfile package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Confirmed
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:
  Confirmed
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:
  In Progress
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--dbgsym package and run:

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

  crash should successfully load, placing you at a "crash>" prompt. At
  that prompt, you can issue the 'bt' command to see a backtrace.

  [Regression Risk]
  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)

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

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

** Description changed:

+ 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.
  
  [Regression Risk]
- TBD
+ 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)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile 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:
  In Progress
Status in makedumpfile package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Confirmed
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:
  Confirmed
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:
  In Progress
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--dbgsym package and run:

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

  crash should successfully load, placing you at a "crash>" prompt. At
  that prompt, you can issue the 'bt' command to see a backtrace.

  [Regression Risk]
  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)

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

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

** No longer affects: kexec-tools (Ubuntu Yakkety)

** Also affects: kexec-tools (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Also affects: makedumpfile (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Changed in: kexec-tools (Ubuntu Yakkety)
   Status: New => Confirmed

** Changed in: kexec-tools (Ubuntu Yakkety)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: makedumpfile (Ubuntu Yakkety)
   Status: New => Confirmed

** Changed in: makedumpfile (Ubuntu Yakkety)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: linux (Ubuntu Yakkety)
   Status: New => Won't Fix

** Changed in: linux (Ubuntu Zesty)
   Status: Confirmed => In Progress

** Changed in: linux (Ubuntu Zesty)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: linux (Ubuntu Xenial)
   Status: Incomplete => Won't Fix

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux 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:
  In Progress
Status in makedumpfile package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Confirmed
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:
  Confirmed
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:
  In Progress
Status in makedumpfile source package in Zesty:
  Confirmed

Bug description:
  [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.

  [Regression Risk]
  TBD

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

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

** Changed in: linux (Ubuntu)
   Status: Confirmed => In Progress

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile 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:
  In Progress
Status in makedumpfile package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Confirmed
Status in linux source package in Xenial:
  Incomplete
Status in makedumpfile source package in Xenial:
  Confirmed
Status in kexec-tools source package in Yakkety:
  Confirmed
Status in kexec-tools source package in Zesty:
  In Progress
Status in linux source package in Zesty:
  Confirmed
Status in makedumpfile source package in Zesty:
  Confirmed

Bug description:
  [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.

  [Regression Risk]
  TBD

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

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

** Changed in: linux (Ubuntu)
 Assignee: (unassigned) => dann frazier (dannf)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile 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:
  Confirmed
Status in makedumpfile package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Confirmed
Status in linux source package in Xenial:
  Incomplete
Status in makedumpfile source package in Xenial:
  Confirmed
Status in kexec-tools source package in Yakkety:
  Confirmed
Status in kexec-tools source package in Zesty:
  In Progress
Status in linux source package in Zesty:
  Confirmed
Status in makedumpfile source package in Zesty:
  Confirmed

Bug description:
  [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.

  [Regression Risk]
  TBD

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

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

By default, kdump-tools does not reserve enough memory for a crashkernel
on arm64. The smallest reservation I've been able to get away with on my
test machine (a Cavium ThunderX crb1s) is 512M.

While kdump-tools currently supports architecture-specific configs, it 
currently has issues that I am attempting to address here:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863858

Adding an arm64 config before that is resolved in Debian may lead to
upgrade complications, so I'd like to wait until is fixed before
installing an arm64-specific config. This means that, for now, arm64
users will need to manually edit their /etc/default/grub.d/kdump-
tools.default config to contain:

GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT
crashkernel=1G-:512M"

** Bug watch added: Debian Bug tracker #863858
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863858

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile 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:
  Confirmed
Status in makedumpfile package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Confirmed
Status in linux source package in Xenial:
  Incomplete
Status in makedumpfile source package in Xenial:
  Confirmed
Status in kexec-tools source package in Yakkety:
  Confirmed
Status in kexec-tools source package in Zesty:
  In Progress
Status in linux source package in Zesty:
  Confirmed
Status in makedumpfile source package in Zesty:
  Confirmed

Bug description:
  [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.

  [Regression Risk]
  TBD

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

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

** Also affects: makedumpfile (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: makedumpfile (Ubuntu)
   Status: New => Confirmed

** Changed in: makedumpfile (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: makedumpfile (Ubuntu Zesty)
   Status: New => Confirmed

** Changed in: kexec-tools (Ubuntu)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: kexec-tools (Ubuntu Zesty)
   Status: Confirmed => In Progress

** Changed in: kexec-tools (Ubuntu Zesty)
 Assignee: (unassigned) => dann frazier (dannf)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux 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:
  Confirmed
Status in makedumpfile package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Confirmed
Status in linux source package in Xenial:
  Incomplete
Status in makedumpfile source package in Xenial:
  Confirmed
Status in kexec-tools source package in Yakkety:
  Confirmed
Status in kexec-tools source package in Zesty:
  In Progress
Status in linux source package in Zesty:
  Confirmed
Status in makedumpfile source package in Zesty:
  Confirmed

Bug description:
  [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.

  [Regression Risk]
  TBD

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

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[Launchpad Bug Tracker]

This bug was fixed in the package kexec-tools - 1:2.0.14-1ubuntu4

---
kexec-tools (1:2.0.14-1ubuntu4) artful; urgency=medium

  * Add backport of upstream arm64 crashdump support (LP: #1694859).

 -- dann frazier   Thu, 08 Jun 2017 17:18:49 -0600

** Changed in: kexec-tools (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux 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:
  Confirmed
Status in kexec-tools source package in Xenial:
  Confirmed
Status in linux source package in Xenial:
  Incomplete
Status in kexec-tools source package in Yakkety:
  Confirmed
Status in kexec-tools source package in Zesty:
  Confirmed
Status in linux source package in Zesty:
  Confirmed

Bug description:
  [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.

  [Regression Risk]
  TBD

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

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

** Description changed:

  [Impact]
  It is not possible to collect a kernel crash dump from a crashed arm64 server 
for later debugging.
  
  [Test Case]
- TBD
+ 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.
  
  [Regression Risk]
  TBD

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

Title:
  arm64 kernel crashdump support

Status in kexec-tools package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Confirmed
Status in linux source package in Xenial:
  Incomplete
Status in kexec-tools source package in Yakkety:
  Confirmed
Status in kexec-tools source package in Zesty:
  Confirmed
Status in linux source package in Zesty:
  Confirmed

Bug description:
  [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.

  [Regression Risk]
  TBD

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

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: kexec-tools (Ubuntu Zesty)
   Status: New => Confirmed

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

Title:
  arm64 kernel crashdump support

Status in kexec-tools package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Confirmed
Status in linux source package in Xenial:
  Incomplete
Status in kexec-tools source package in Yakkety:
  Confirmed
Status in kexec-tools source package in Zesty:
  Confirmed
Status in linux source package in Zesty:
  Confirmed

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

  [Test Case]
  TBD

  [Regression Risk]
  TBD

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

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: kexec-tools (Ubuntu)
   Status: New => Confirmed

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

Title:
  arm64 kernel crashdump support

Status in kexec-tools package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Confirmed
Status in linux source package in Xenial:
  Incomplete
Status in kexec-tools source package in Yakkety:
  Confirmed
Status in kexec-tools source package in Zesty:
  Confirmed
Status in linux source package in Zesty:
  Confirmed

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

  [Test Case]
  TBD

  [Regression Risk]
  TBD

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

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: kexec-tools (Ubuntu Yakkety)
   Status: New => Confirmed

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

Title:
  arm64 kernel crashdump support

Status in kexec-tools package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Confirmed
Status in linux source package in Xenial:
  Incomplete
Status in kexec-tools source package in Yakkety:
  Confirmed
Status in kexec-tools source package in Zesty:
  Confirmed
Status in linux source package in Zesty:
  Confirmed

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

  [Test Case]
  TBD

  [Regression Risk]
  TBD

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

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: kexec-tools (Ubuntu Xenial)
   Status: New => Confirmed

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

Title:
  arm64 kernel crashdump support

Status in kexec-tools package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Confirmed
Status in linux source package in Xenial:
  Incomplete
Status in kexec-tools source package in Yakkety:
  Confirmed
Status in kexec-tools source package in Zesty:
  Confirmed
Status in linux source package in Zesty:
  Confirmed

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

  [Test Case]
  TBD

  [Regression Risk]
  TBD

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

[Kernel-packages] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

** Changed in: linux (Ubuntu)
   Status: Incomplete => Confirmed

** Changed in: linux (Ubuntu Zesty)
   Status: Incomplete => Confirmed

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

Title:
  arm64 kernel crashdump support

Status in kexec-tools package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  New
Status in linux source package in Xenial:
  Incomplete
Status in kexec-tools source package in Yakkety:
  New
Status in kexec-tools source package in Zesty:
  New
Status in linux source package in Zesty:
  Confirmed

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

  [Test Case]
  TBD

  [Regression Risk]
  TBD

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