| 2017-05-31 23:47:59 |
dann frazier |
bug |
|
|
added bug |
| 2017-05-31 23:48:15 |
dann frazier |
nominated for series |
|
Ubuntu Zesty |
|
| 2017-05-31 23:48:15 |
dann frazier |
bug task added |
|
linux (Ubuntu Zesty) |
|
| 2017-05-31 23:48:27 |
dann frazier |
bug task added |
|
kexec-tools (Ubuntu) |
|
| 2017-05-31 23:48:43 |
dann frazier |
nominated for series |
|
Ubuntu Yakkety |
|
| 2017-05-31 23:48:43 |
dann frazier |
bug task added |
|
kexec-tools (Ubuntu Yakkety) |
|
| 2017-05-31 23:48:43 |
dann frazier |
bug task added |
|
linux (Ubuntu Yakkety) |
|
| 2017-05-31 23:48:43 |
dann frazier |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-05-31 23:48:43 |
dann frazier |
bug task added |
|
kexec-tools (Ubuntu Xenial) |
|
| 2017-05-31 23:48:43 |
dann frazier |
bug task added |
|
linux (Ubuntu Xenial) |
|
| 2017-05-31 23:50:00 |
dann frazier |
bug task deleted |
linux (Ubuntu Yakkety) |
|
|
| 2017-06-01 00:00:14 |
Brad Figg |
linux (Ubuntu): status |
New |
Incomplete |
|
| 2017-06-01 00:00:17 |
Brad Figg |
linux (Ubuntu Xenial): status |
New |
Incomplete |
|
| 2017-06-01 00:00:20 |
Brad Figg |
linux (Ubuntu Zesty): status |
New |
Incomplete |
|
| 2017-06-01 02:10:01 |
dann frazier |
linux (Ubuntu): status |
Incomplete |
Confirmed |
|
| 2017-06-01 02:10:04 |
dann frazier |
linux (Ubuntu Zesty): status |
Incomplete |
Confirmed |
|
| 2017-06-02 16:22:03 |
Launchpad Janitor |
kexec-tools (Ubuntu): status |
New |
Confirmed |
|
| 2017-06-02 16:22:03 |
Launchpad Janitor |
kexec-tools (Ubuntu Xenial): status |
New |
Confirmed |
|
| 2017-06-02 16:22:03 |
Launchpad Janitor |
kexec-tools (Ubuntu Yakkety): status |
New |
Confirmed |
|
| 2017-06-02 16:22:03 |
Launchpad Janitor |
kexec-tools (Ubuntu Zesty): status |
New |
Confirmed |
|
| 2017-06-08 23:20:14 |
dann frazier |
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 |
[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 |
|
| 2017-06-09 00:42:00 |
Launchpad Janitor |
kexec-tools (Ubuntu): status |
Confirmed |
Fix Released |
|
| 2017-06-15 18:50:59 |
dann frazier |
bug task added |
|
makedumpfile (Ubuntu) |
|
| 2017-06-15 18:51:18 |
dann frazier |
makedumpfile (Ubuntu): status |
New |
Confirmed |
|
| 2017-06-15 18:51:32 |
dann frazier |
makedumpfile (Ubuntu Xenial): status |
New |
Confirmed |
|
| 2017-06-15 18:51:42 |
dann frazier |
makedumpfile (Ubuntu Zesty): status |
New |
Confirmed |
|
| 2017-06-15 18:58:19 |
dann frazier |
kexec-tools (Ubuntu): assignee |
|
dann frazier (dannf) |
|
| 2017-06-15 18:58:37 |
dann frazier |
kexec-tools (Ubuntu Zesty): status |
Confirmed |
In Progress |
|
| 2017-06-15 18:58:37 |
dann frazier |
kexec-tools (Ubuntu Zesty): assignee |
|
dann frazier (dannf) |
|
| 2017-06-15 19:09:08 |
dann frazier |
bug watch added |
|
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863858 |
|
| 2017-06-20 21:30:11 |
dann frazier |
linux (Ubuntu): assignee |
|
dann frazier (dannf) |
|
| 2017-06-20 23:15:58 |
dann frazier |
linux (Ubuntu): status |
Confirmed |
In Progress |
|
| 2017-06-20 23:34:07 |
dann frazier |
bug task deleted |
kexec-tools (Ubuntu Yakkety) |
|
|
| 2017-06-20 23:34:15 |
dann frazier |
nominated for series |
|
Ubuntu Yakkety |
|
| 2017-06-20 23:34:15 |
dann frazier |
bug task added |
|
kexec-tools (Ubuntu Yakkety) |
|
| 2017-06-20 23:34:15 |
dann frazier |
bug task added |
|
linux (Ubuntu Yakkety) |
|
| 2017-06-20 23:34:15 |
dann frazier |
bug task added |
|
makedumpfile (Ubuntu Yakkety) |
|
| 2017-06-20 23:34:58 |
dann frazier |
kexec-tools (Ubuntu Yakkety): status |
New |
Confirmed |
|
| 2017-06-20 23:34:58 |
dann frazier |
kexec-tools (Ubuntu Yakkety): assignee |
|
dann frazier (dannf) |
|
| 2017-06-20 23:35:32 |
dann frazier |
makedumpfile (Ubuntu Yakkety): status |
New |
Confirmed |
|
| 2017-06-20 23:35:32 |
dann frazier |
makedumpfile (Ubuntu Yakkety): assignee |
|
dann frazier (dannf) |
|
| 2017-06-20 23:35:54 |
dann frazier |
linux (Ubuntu Yakkety): status |
New |
Won't Fix |
|
| 2017-06-20 23:36:43 |
dann frazier |
linux (Ubuntu Zesty): status |
Confirmed |
In Progress |
|
| 2017-06-20 23:36:43 |
dann frazier |
linux (Ubuntu Zesty): assignee |
|
dann frazier (dannf) |
|
| 2017-06-20 23:37:16 |
dann frazier |
linux (Ubuntu Xenial): status |
Incomplete |
Won't Fix |
|
| 2017-06-21 00:14:22 |
dann frazier |
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 |
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]
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) |
|
| 2017-06-21 00:20:06 |
dann frazier |
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.
[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) |
Note: Updates are being staged at ppa:dannf/arm64-kdump.
[Impact]
It is not possible to collect a kernel crash dump from a crashed arm64 server for later debugging.
[Test Case]
sudo apt install kdump-tools
(reboot, so crashkernel= is added to the kernel commandline)
echo c | sudo tee /proc/sysrq-trigger
Crash dump should occur, with artifacts collected in /var/crash.
If you want to verify that the dump is usable, install the corresponding linux-image-<ver>-dbgsym package and run:
sudo crash /usr/lib/debug/boot/vmlinux-<ver> /var/crash/<crash>/dump.<crash>
crash should successfully load, placing you at a "crash>" prompt. At that prompt, you can issue the 'bt' command to see a backtrace.
[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) |
|
| 2017-06-21 12:00:07 |
Stefan Bader |
linux (Ubuntu Zesty): importance |
Undecided |
Medium |
|
| 2017-06-21 12:00:07 |
Stefan Bader |
linux (Ubuntu Zesty): status |
In Progress |
Fix Committed |
|
| 2017-06-21 14:57:38 |
Manoj Iyer |
tags |
|
qdf2400 |
|
| 2017-06-21 20:51:35 |
dann frazier |
kexec-tools (Ubuntu Xenial): assignee |
|
dann frazier (dannf) |
|
| 2017-06-21 20:52:00 |
dann frazier |
makedumpfile (Ubuntu): assignee |
|
dann frazier (dannf) |
|
| 2017-06-21 20:52:17 |
dann frazier |
makedumpfile (Ubuntu Xenial): assignee |
|
dann frazier (dannf) |
|
| 2017-06-21 20:52:35 |
dann frazier |
makedumpfile (Ubuntu Zesty): assignee |
|
dann frazier (dannf) |
|
| 2017-06-21 20:54:00 |
dann frazier |
linux (Ubuntu): status |
In Progress |
Fix Committed |
|
| 2017-06-22 01:47:55 |
dann frazier |
description |
Note: Updates are being staged at ppa:dannf/arm64-kdump.
[Impact]
It is not possible to collect a kernel crash dump from a crashed arm64 server for later debugging.
[Test Case]
sudo apt install kdump-tools
(reboot, so crashkernel= is added to the kernel commandline)
echo c | sudo tee /proc/sysrq-trigger
Crash dump should occur, with artifacts collected in /var/crash.
If you want to verify that the dump is usable, install the corresponding linux-image-<ver>-dbgsym package and run:
sudo crash /usr/lib/debug/boot/vmlinux-<ver> /var/crash/<crash>/dump.<crash>
crash should successfully load, placing you at a "crash>" prompt. At that prompt, you can issue the 'bt' command to see a backtrace.
[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) |
Note: Updates are being staged at ppa:dannf/arm64-kdump.
[Impact]
It is not possible to collect a kernel crash dump from a crashed arm64 server for later debugging.
[Test Case]
sudo apt install kdump-tools
(reboot, so crashkernel= is added to the kernel commandline)
echo c | sudo tee /proc/sysrq-trigger
Crash dump should occur, with artifacts collected in /var/crash.
If you want to verify that the dump is usable, install the corresponding linux-image-<ver>-dbgsym package and run:
sudo crash /usr/lib/debug/boot/vmlinux-<ver> /var/crash/<crash>/dump.<crash>
crash should successfully load, placing you at a "crash>" prompt. At that prompt, you can issue the 'bt' command to see a backtrace.
[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 |
|
| 2017-06-22 19:21:49 |
dann frazier |
description |
Note: Updates are being staged at ppa:dannf/arm64-kdump.
[Impact]
It is not possible to collect a kernel crash dump from a crashed arm64 server for later debugging.
[Test Case]
sudo apt install kdump-tools
(reboot, so crashkernel= is added to the kernel commandline)
echo c | sudo tee /proc/sysrq-trigger
Crash dump should occur, with artifacts collected in /var/crash.
If you want to verify that the dump is usable, install the corresponding linux-image-<ver>-dbgsym package and run:
sudo crash /usr/lib/debug/boot/vmlinux-<ver> /var/crash/<crash>/dump.<crash>
crash should successfully load, placing you at a "crash>" prompt. At that prompt, you can issue the 'bt' command to see a backtrace.
[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 |
Note: Updates are being staged at ppa:dannf/arm64-kdump.
[Impact]
It is not possible to collect a kernel crash dump from a crashed arm64 server for later debugging.
[Test Case]
sudo apt install kdump-tools
(reboot, so crashkernel= is added to the kernel commandline)
echo c | sudo tee /proc/sysrq-trigger
Crash dump should occur, with artifacts collected in /var/crash.
If you want to verify that the dump is usable, install the corresponding linux-image-<ver>-dbgsym package and run:
sudo crash /usr/lib/debug/boot/vmlinux-<ver> /var/crash/<crash>/dump.<crash>
crash should successfully load, placing you at a "crash>" prompt. At that prompt, you can issue the 'bt' command to see a backtrace.
[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. |
|
| 2017-06-23 17:46:19 |
dann frazier |
kexec-tools (Ubuntu Yakkety): status |
Confirmed |
In Progress |
|
| 2017-06-23 18:25:37 |
dann frazier |
description |
Note: Updates are being staged at ppa:dannf/arm64-kdump.
[Impact]
It is not possible to collect a kernel crash dump from a crashed arm64 server for later debugging.
[Test Case]
sudo apt install kdump-tools
(reboot, so crashkernel= is added to the kernel commandline)
echo c | sudo tee /proc/sysrq-trigger
Crash dump should occur, with artifacts collected in /var/crash.
If you want to verify that the dump is usable, install the corresponding linux-image-<ver>-dbgsym package and run:
sudo crash /usr/lib/debug/boot/vmlinux-<ver> /var/crash/<crash>/dump.<crash>
crash should successfully load, placing you at a "crash>" prompt. At that prompt, you can issue the 'bt' command to see a backtrace.
[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. |
Note: Updates are being staged at ppa:dannf/arm64-kdump.
[Impact]
It is not possible to collect a kernel crash dump from a crashed arm64 server for later debugging.
[Test Case]
sudo apt install kdump-tools
(reboot, so crashkernel= is added to the kernel commandline)
echo c | sudo tee /proc/sysrq-trigger
Crash dump should occur, with artifacts collected in /var/crash.
If you want to verify that the dump is usable, install the corresponding linux-image-<ver>-dbgsym package and run:
sudo crash /usr/lib/debug/boot/vmlinux-<ver> /var/crash/<crash>/dump.<crash>
crash should successfully load, placing you at a "crash>" prompt. At that prompt, you can issue the 'bt' command to see a backtrace.
[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. |
|
| 2017-06-23 19:11:29 |
dann frazier |
kexec-tools (Ubuntu Xenial): status |
Confirmed |
In Progress |
|
| 2017-06-23 22:40:34 |
dann frazier |
description |
Note: Updates are being staged at ppa:dannf/arm64-kdump.
[Impact]
It is not possible to collect a kernel crash dump from a crashed arm64 server for later debugging.
[Test Case]
sudo apt install kdump-tools
(reboot, so crashkernel= is added to the kernel commandline)
echo c | sudo tee /proc/sysrq-trigger
Crash dump should occur, with artifacts collected in /var/crash.
If you want to verify that the dump is usable, install the corresponding linux-image-<ver>-dbgsym package and run:
sudo crash /usr/lib/debug/boot/vmlinux-<ver> /var/crash/<crash>/dump.<crash>
crash should successfully load, placing you at a "crash>" prompt. At that prompt, you can issue the 'bt' command to see a backtrace.
[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. |
Note: Updates are being staged at ppa:dannf/arm64-kdump.
[Impact]
It is not possible to collect a kernel crash dump from a crashed arm64 server for later debugging.
[Test Case]
sudo apt install kdump-tools
(reboot, so crashkernel= is added to the kernel commandline)
echo c | sudo tee /proc/sysrq-trigger
Crash dump should occur, with artifacts collected in /var/crash.
If you want to verify that the dump is usable, install the corresponding linux-image-<ver>-dbgsym package and run:
sudo crash /usr/lib/debug/boot/vmlinux-<ver> /var/crash/<crash>/dump.<crash>
crash should successfully load, placing you at a "crash>" prompt. At that prompt, you can issue the 'bt' command to see a backtrace.
Note: you need crash from zesty (7.1.8-1ubuntu1) or later.
[Regression Risk]
= Kernel =
3 patches here touch code outside of arch/arm64/:
memblock: add memblock_clear_nomap()
This adds a new function with no callers, so regression risk is negligible.
(A later patch adds a call to it under arch/arm64/).
memblock: add memblock_cap_memory_range()
This refactors some of the code in memblock_mem_limit_remove_map() into a new function. The only existing caller of memblock_mem_limit_remove_map() is under arch/arm64/, so the regression risk outside of arm64 is negligible.
efi/libstub/arm*: Set default address and size cells values for an empty dtb
Because this code is for EFI platforms that support device-tree, it is de-facto ARM-specific (as noted in the patch title).
For arm64, we have mitigated the risk by explicit regression testing on several platforms:
- Qualcomm QDF2400
- Cavium ThunderX CRB1S
- HP m400 (X-Gene)
- HiSilicon D05 (Hi07)
= kexec-tools =
== zesty ==
For zesty, 10 patches are required to add kdump support.
0001-kexec-extend-the-semantics-of-kexec_iomem_for_each_l.patch:
This modifies a function used on armhf & x86. The description explains the change, and why it does not impact those archs:
-----
The current users of kexec_iomem_for_each_line(), arm, sh and x86, will not
be affected by this change because
* arm
The callback function only returns -1 or 0, and the return value of
kexec_iomem_for_each_line() will never be used.
* sh, x86
The callback function may return (-1 for sh,) 0 or 1, but always returns
1 once we have reached the maximum number of entries allowed.
Even so the current kexec_iomem_for_each_line() counts them up.
This change actually fixes this bug.
-----
0002-kexec-generalize-and-rename-get_kernel_stext_sym.patch:
This generalizes a function that was duplicated by arm & x86 and makes it common so arm64 can use it.
The remaining 8 of these only touch code in kexec/arch/arm64, so regression risk for other architectures is negligible.
Finally, I have tested this update on both i386 and amd64 VMs. i386 crashes do not currently work in zesty (filed LP: #1699874), and my test results show no change there. amd64 worked before, and continues to work with these changes.
== yakkety ==
Since yakkety is based on an older upstream, 6 additional patches are required:
arm-fix-get_kernel_stext_sym-to-close-its-file.patch:
This is a cleanup patch, cherry-picked because it allows later patches to apply w/o backporting. ARM-specific.
kexec-add-max_size-to-memory_ranges.patch:
Adds a new element to struct, to be used by later commits.
kexec-add-generic-helper-to-add-to-memoryq_regions.patch,
kexec-add-mem_regions-sorting-implementation.patch,
kexec-add-helper-to-exlude-a-region-from-a-set-of-me.patch,
kexec-fix-mem_regions_sort.patch:
These patches only add new functions, which will be used by later patches.
kexec-arch-i386-Add-support-for-KASLR-memory-randomi.patch:
This is a bug fix or i386 that allows later patches to apply w/o backporting.
kdump support for i386 is apparently broken for the yakkety kernel (see LP: #1699874) so, if this introduces a regression, it won't be detectable.
(I checked to see if this *fixes* i386 crashdumps - it does not).
Note that, while makedumpfile in >= zesty is new enough to work on arm64, the yakkety version does not. kdump-tools falls back to copying the entire vmcore, which is what I tested.
As with zesty, I have tested this update on both i386 and amd64 VMs. i386 crashes do not currently work in yakkety, and my test results show no change there. amd64 worked before, and continues to work with these changes. |
|
| 2017-06-23 22:50:16 |
dann frazier |
description |
Note: Updates are being staged at ppa:dannf/arm64-kdump.
[Impact]
It is not possible to collect a kernel crash dump from a crashed arm64 server for later debugging.
[Test Case]
sudo apt install kdump-tools
(reboot, so crashkernel= is added to the kernel commandline)
echo c | sudo tee /proc/sysrq-trigger
Crash dump should occur, with artifacts collected in /var/crash.
If you want to verify that the dump is usable, install the corresponding linux-image-<ver>-dbgsym package and run:
sudo crash /usr/lib/debug/boot/vmlinux-<ver> /var/crash/<crash>/dump.<crash>
crash should successfully load, placing you at a "crash>" prompt. At that prompt, you can issue the 'bt' command to see a backtrace.
Note: you need crash from zesty (7.1.8-1ubuntu1) or later.
[Regression Risk]
= Kernel =
3 patches here touch code outside of arch/arm64/:
memblock: add memblock_clear_nomap()
This adds a new function with no callers, so regression risk is negligible.
(A later patch adds a call to it under arch/arm64/).
memblock: add memblock_cap_memory_range()
This refactors some of the code in memblock_mem_limit_remove_map() into a new function. The only existing caller of memblock_mem_limit_remove_map() is under arch/arm64/, so the regression risk outside of arm64 is negligible.
efi/libstub/arm*: Set default address and size cells values for an empty dtb
Because this code is for EFI platforms that support device-tree, it is de-facto ARM-specific (as noted in the patch title).
For arm64, we have mitigated the risk by explicit regression testing on several platforms:
- Qualcomm QDF2400
- Cavium ThunderX CRB1S
- HP m400 (X-Gene)
- HiSilicon D05 (Hi07)
= kexec-tools =
== zesty ==
For zesty, 10 patches are required to add kdump support.
0001-kexec-extend-the-semantics-of-kexec_iomem_for_each_l.patch:
This modifies a function used on armhf & x86. The description explains the change, and why it does not impact those archs:
-----
The current users of kexec_iomem_for_each_line(), arm, sh and x86, will not
be affected by this change because
* arm
The callback function only returns -1 or 0, and the return value of
kexec_iomem_for_each_line() will never be used.
* sh, x86
The callback function may return (-1 for sh,) 0 or 1, but always returns
1 once we have reached the maximum number of entries allowed.
Even so the current kexec_iomem_for_each_line() counts them up.
This change actually fixes this bug.
-----
0002-kexec-generalize-and-rename-get_kernel_stext_sym.patch:
This generalizes a function that was duplicated by arm & x86 and makes it common so arm64 can use it.
The remaining 8 of these only touch code in kexec/arch/arm64, so regression risk for other architectures is negligible.
Finally, I have tested this update on both i386 and amd64 VMs. i386 crashes do not currently work in zesty (filed LP: #1699874), and my test results show no change there. amd64 worked before, and continues to work with these changes.
== yakkety ==
Since yakkety is based on an older upstream, 6 additional patches are required:
arm-fix-get_kernel_stext_sym-to-close-its-file.patch:
This is a cleanup patch, cherry-picked because it allows later patches to apply w/o backporting. ARM-specific.
kexec-add-max_size-to-memory_ranges.patch:
Adds a new element to struct, to be used by later commits.
kexec-add-generic-helper-to-add-to-memoryq_regions.patch,
kexec-add-mem_regions-sorting-implementation.patch,
kexec-add-helper-to-exlude-a-region-from-a-set-of-me.patch,
kexec-fix-mem_regions_sort.patch:
These patches only add new functions, which will be used by later patches.
kexec-arch-i386-Add-support-for-KASLR-memory-randomi.patch:
This is a bug fix or i386 that allows later patches to apply w/o backporting.
kdump support for i386 is apparently broken for the yakkety kernel (see LP: #1699874) so, if this introduces a regression, it won't be detectable.
(I checked to see if this *fixes* i386 crashdumps - it does not).
Note that, while makedumpfile in >= zesty is new enough to work on arm64, the yakkety version does not. kdump-tools falls back to copying the entire vmcore, which is what I tested.
As with zesty, I have tested this update on both i386 and amd64 VMs. i386 crashes do not currently work in yakkety, and my test results show no change there. amd64 worked before, and continues to work with these changes. |
Note: Updates are being staged at ppa:dannf/arm64-kdump.
[Impact]
It is not possible to collect a kernel crash dump from a crashed arm64 server for later debugging.
[Test Case]
sudo apt install kdump-tools
(reboot, so crashkernel= is added to the kernel commandline)
echo c | sudo tee /proc/sysrq-trigger
Crash dump should occur, with artifacts collected in /var/crash.
If you want to verify that the dump is usable, install the corresponding linux-image-<ver>-dbgsym package and run:
sudo crash /usr/lib/debug/boot/vmlinux-<ver> /var/crash/<crash>/dump.<crash>
crash should successfully load, placing you at a "crash>" prompt. At that prompt, you can issue the 'bt' command to see a backtrace.
Note: you need crash from zesty (7.1.8-1ubuntu1) or later.
[Regression Risk]
= Kernel =
3 patches here touch code outside of arch/arm64/:
memblock: add memblock_clear_nomap()
This adds a new function with no callers, so regression risk is negligible.
(A later patch adds a call to it under arch/arm64/).
memblock: add memblock_cap_memory_range()
This refactors some of the code in memblock_mem_limit_remove_map() into a new function. The only existing caller of memblock_mem_limit_remove_map() is under arch/arm64/, so the regression risk outside of arm64 is negligible.
efi/libstub/arm*: Set default address and size cells values for an empty dtb
Because this code is for EFI platforms that support device-tree, it is de-facto ARM-specific (as noted in the patch title).
For arm64, we have mitigated the risk by explicit regression testing on several platforms:
- Qualcomm QDF2400
- Cavium ThunderX CRB1S
- HP m400 (X-Gene)
- HiSilicon D05 (Hi07)
= kexec-tools =
== zesty ==
For zesty, 10 patches are required to add kdump support.
0001-kexec-extend-the-semantics-of-kexec_iomem_for_each_l.patch:
This modifies a function used on armhf & x86. The description explains the change, and why it does not impact those archs:
-----
The current users of kexec_iomem_for_each_line(), arm, sh and x86, will not
be affected by this change because
* arm
The callback function only returns -1 or 0, and the return value of
kexec_iomem_for_each_line() will never be used.
* sh, x86
The callback function may return (-1 for sh,) 0 or 1, but always returns
1 once we have reached the maximum number of entries allowed.
Even so the current kexec_iomem_for_each_line() counts them up.
This change actually fixes this bug.
-----
0002-kexec-generalize-and-rename-get_kernel_stext_sym.patch:
This generalizes a function that was duplicated by arm & x86 and makes it common so arm64 can use it.
The remaining 8 of these only touch code in kexec/arch/arm64, so regression risk for other architectures is negligible.
Finally, I have tested this update on both i386 and amd64 VMs. i386 crashes do not currently work in zesty (filed LP: #1699874), and my test results show no change there. amd64 worked before, and continues to work with these changes.
== yakkety ==
Since yakkety is based on an older upstream, 6 additional patches are required:
arm-fix-get_kernel_stext_sym-to-close-its-file.patch:
This is a cleanup patch, cherry-picked because it allows later patches to apply w/o backporting. ARM-specific.
kexec-add-max_size-to-memory_ranges.patch:
Adds a new element to struct, to be used by later commits.
kexec-add-generic-helper-to-add-to-memoryq_regions.patch,
kexec-add-mem_regions-sorting-implementation.patch,
kexec-add-helper-to-exlude-a-region-from-a-set-of-me.patch,
kexec-fix-mem_regions_sort.patch:
These patches only add new functions, which will be used by later patches.
kexec-arch-i386-Add-support-for-KASLR-memory-randomi.patch:
This is a bug fix or i386 that allows later patches to apply w/o backporting.
kdump support for i386 is apparently broken for the yakkety kernel (see LP: #1699874) so, if this introduces a regression, it won't be detectable.
(I checked to see if this *fixes* i386 crashdumps - it does not).
Note that, while makedumpfile in >= zesty is new enough to work on arm64, the yakkety version does not. kdump-tools falls back to copying the entire vmcore, which is what I tested.
As with zesty, I have tested this update on both i386 and amd64 VMs. i386 crashes do not currently work in yakkety, and my test results show no change there. amd64 worked before, and continues to work with these changes.
= xenial =
The patchset needed for xenial is identical to the patchset for yakkety. The only additional change is to add arm64 to the list of archs that get a /etc/default/grub.d snippet (in yakkety that snippet moved over to kdump-tools), and that has negligible regression risk for !arm64. |
|
| 2017-06-23 22:54:20 |
dann frazier |
description |
Note: Updates are being staged at ppa:dannf/arm64-kdump.
[Impact]
It is not possible to collect a kernel crash dump from a crashed arm64 server for later debugging.
[Test Case]
sudo apt install kdump-tools
(reboot, so crashkernel= is added to the kernel commandline)
echo c | sudo tee /proc/sysrq-trigger
Crash dump should occur, with artifacts collected in /var/crash.
If you want to verify that the dump is usable, install the corresponding linux-image-<ver>-dbgsym package and run:
sudo crash /usr/lib/debug/boot/vmlinux-<ver> /var/crash/<crash>/dump.<crash>
crash should successfully load, placing you at a "crash>" prompt. At that prompt, you can issue the 'bt' command to see a backtrace.
Note: you need crash from zesty (7.1.8-1ubuntu1) or later.
[Regression Risk]
= Kernel =
3 patches here touch code outside of arch/arm64/:
memblock: add memblock_clear_nomap()
This adds a new function with no callers, so regression risk is negligible.
(A later patch adds a call to it under arch/arm64/).
memblock: add memblock_cap_memory_range()
This refactors some of the code in memblock_mem_limit_remove_map() into a new function. The only existing caller of memblock_mem_limit_remove_map() is under arch/arm64/, so the regression risk outside of arm64 is negligible.
efi/libstub/arm*: Set default address and size cells values for an empty dtb
Because this code is for EFI platforms that support device-tree, it is de-facto ARM-specific (as noted in the patch title).
For arm64, we have mitigated the risk by explicit regression testing on several platforms:
- Qualcomm QDF2400
- Cavium ThunderX CRB1S
- HP m400 (X-Gene)
- HiSilicon D05 (Hi07)
= kexec-tools =
== zesty ==
For zesty, 10 patches are required to add kdump support.
0001-kexec-extend-the-semantics-of-kexec_iomem_for_each_l.patch:
This modifies a function used on armhf & x86. The description explains the change, and why it does not impact those archs:
-----
The current users of kexec_iomem_for_each_line(), arm, sh and x86, will not
be affected by this change because
* arm
The callback function only returns -1 or 0, and the return value of
kexec_iomem_for_each_line() will never be used.
* sh, x86
The callback function may return (-1 for sh,) 0 or 1, but always returns
1 once we have reached the maximum number of entries allowed.
Even so the current kexec_iomem_for_each_line() counts them up.
This change actually fixes this bug.
-----
0002-kexec-generalize-and-rename-get_kernel_stext_sym.patch:
This generalizes a function that was duplicated by arm & x86 and makes it common so arm64 can use it.
The remaining 8 of these only touch code in kexec/arch/arm64, so regression risk for other architectures is negligible.
Finally, I have tested this update on both i386 and amd64 VMs. i386 crashes do not currently work in zesty (filed LP: #1699874), and my test results show no change there. amd64 worked before, and continues to work with these changes.
== yakkety ==
Since yakkety is based on an older upstream, 6 additional patches are required:
arm-fix-get_kernel_stext_sym-to-close-its-file.patch:
This is a cleanup patch, cherry-picked because it allows later patches to apply w/o backporting. ARM-specific.
kexec-add-max_size-to-memory_ranges.patch:
Adds a new element to struct, to be used by later commits.
kexec-add-generic-helper-to-add-to-memoryq_regions.patch,
kexec-add-mem_regions-sorting-implementation.patch,
kexec-add-helper-to-exlude-a-region-from-a-set-of-me.patch,
kexec-fix-mem_regions_sort.patch:
These patches only add new functions, which will be used by later patches.
kexec-arch-i386-Add-support-for-KASLR-memory-randomi.patch:
This is a bug fix or i386 that allows later patches to apply w/o backporting.
kdump support for i386 is apparently broken for the yakkety kernel (see LP: #1699874) so, if this introduces a regression, it won't be detectable.
(I checked to see if this *fixes* i386 crashdumps - it does not).
Note that, while makedumpfile in >= zesty is new enough to work on arm64, the yakkety version does not. kdump-tools falls back to copying the entire vmcore, which is what I tested.
As with zesty, I have tested this update on both i386 and amd64 VMs. i386 crashes do not currently work in yakkety, and my test results show no change there. amd64 worked before, and continues to work with these changes.
= xenial =
The patchset needed for xenial is identical to the patchset for yakkety. The only additional change is to add arm64 to the list of archs that get a /etc/default/grub.d snippet (in yakkety that snippet moved over to kdump-tools), and that has negligible regression risk for !arm64. |
Note: Updates are being staged at ppa:dannf/arm64-kdump.
[Impact]
It is not possible to collect a kernel crash dump from a crashed arm64 server for later debugging.
[Test Case]
sudo apt install kdump-tools
(reboot, so crashkernel= is added to the kernel commandline)
echo c | sudo tee /proc/sysrq-trigger
Crash dump should occur, with artifacts collected in /var/crash.
If you want to verify that the dump is usable, install the corresponding linux-image-<ver>-dbgsym package and run:
sudo crash /usr/lib/debug/boot/vmlinux-<ver> /var/crash/<crash>/dump.<crash>
crash should successfully load, placing you at a "crash>" prompt. At that prompt, you can issue the 'bt' command to see a backtrace.
Note: you need crash from zesty (7.1.8-1ubuntu1) or later.
[Regression Risk]
= Kernel =
3 patches here touch code outside of arch/arm64/:
memblock: add memblock_clear_nomap()
This adds a new function with no callers, so regression risk is negligible.
(A later patch adds a call to it under arch/arm64/).
memblock: add memblock_cap_memory_range()
This refactors some of the code in memblock_mem_limit_remove_map() into a new function. The only existing caller of memblock_mem_limit_remove_map() is under arch/arm64/, so the regression risk outside of arm64 is negligible.
efi/libstub/arm*: Set default address and size cells values for an empty dtb
Because this code is for EFI platforms that support device-tree, it is de-facto ARM-specific (as noted in the patch title).
For arm64, we have mitigated the risk by explicit regression testing on several platforms:
- Qualcomm QDF2400
- Cavium ThunderX CRB1S
- HP m400 (X-Gene)
- HiSilicon D05 (Hi07)
= kexec-tools =
== zesty ==
For zesty, 10 patches are required to add kdump support.
0001-kexec-extend-the-semantics-of-kexec_iomem_for_each_l.patch:
This modifies a function used on armhf & x86. The description explains the change, and why it does not impact those archs:
-----
The current users of kexec_iomem_for_each_line(), arm, sh and x86, will not
be affected by this change because
* arm
The callback function only returns -1 or 0, and the return value of
kexec_iomem_for_each_line() will never be used.
* sh, x86
The callback function may return (-1 for sh,) 0 or 1, but always returns
1 once we have reached the maximum number of entries allowed.
Even so the current kexec_iomem_for_each_line() counts them up.
This change actually fixes this bug.
-----
0002-kexec-generalize-and-rename-get_kernel_stext_sym.patch:
This generalizes a function that was duplicated by arm & x86 and makes it common so arm64 can use it.
The remaining 8 of these only touch code in kexec/arch/arm64, so regression risk for other architectures is negligible.
Finally, I have tested this update on both i386 and amd64 VMs. i386 crashes do not currently work in zesty (filed LP: #1699874), and my test results show no change there. amd64 worked before, and continues to work with these changes.
== yakkety ==
Since yakkety is based on an older upstream, 6 additional patches are required:
arm-fix-get_kernel_stext_sym-to-close-its-file.patch:
This is a cleanup patch, cherry-picked because it allows later patches to apply w/o backporting. ARM-specific.
kexec-add-max_size-to-memory_ranges.patch:
Adds a new element to struct, to be used by later commits.
kexec-add-generic-helper-to-add-to-memoryq_regions.patch,
kexec-add-mem_regions-sorting-implementation.patch,
kexec-add-helper-to-exlude-a-region-from-a-set-of-me.patch,
kexec-fix-mem_regions_sort.patch:
These patches only add new functions, which will be used by later patches.
kexec-arch-i386-Add-support-for-KASLR-memory-randomi.patch:
This is a bug fix or i386 that allows later patches to apply w/o backporting.
kdump support for i386 is apparently broken for the yakkety kernel (see LP: #1699874) so, if this introduces a regression, it won't be detectable.
(I checked to see if this *fixes* i386 crashdumps - it does not).
Note that, while makedumpfile in >= zesty is new enough to work on arm64, the yakkety version does not. kdump-tools falls back to copying the entire vmcore, which is what I tested.
As with zesty, I have tested this update on both i386 and amd64 VMs. i386 crashes do not currently work in yakkety, and my test results show no change there. amd64 worked before, and continues to work with these changes.
= xenial =
The patchset needed for xenial is identical to the patchset for yakkety. The only additional change is to add arm64 to the list of archs that get a /etc/default/grub.d snippet (in yakkety that snippet moved over to kdump-tools), and that has negligible regression risk for !arm64.
I performed the same testing as with yakkety. The only significant difference is that i386 worked before and after this update (for y/z/a it worked neither before nor after). |
|
| 2017-07-10 08:23:32 |
Kleber Sacilotto de Souza |
tags |
qdf2400 |
qdf2400 verification-needed-zesty |
|
| 2017-07-10 21:55:34 |
dann frazier |
tags |
qdf2400 verification-needed-zesty |
qdf2400 verification-done-zesty |
|
| 2017-07-12 12:13:16 |
Launchpad Janitor |
linux (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2017-07-13 19:13:40 |
Brian Murray |
kexec-tools (Ubuntu Zesty): status |
In Progress |
Fix Committed |
|
| 2017-07-13 19:13:43 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-07-13 19:13:45 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2017-07-13 19:13:50 |
Brian Murray |
tags |
qdf2400 verification-done-zesty |
qdf2400 verification-needed verification-needed-zesty |
|
| 2017-07-13 19:19:49 |
Brian Murray |
kexec-tools (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2017-07-13 19:19:58 |
Brian Murray |
tags |
qdf2400 verification-needed verification-needed-zesty |
qdf2400 verification-needed verification-needed-xenial verification-needed-zesty |
|
| 2017-07-17 11:57:59 |
Launchpad Janitor |
linux (Ubuntu Zesty): status |
Fix Committed |
Fix Released |
|
| 2017-07-17 11:57:59 |
Launchpad Janitor |
cve linked |
|
2014-9900 |
|
| 2017-07-17 11:57:59 |
Launchpad Janitor |
cve linked |
|
2017-1000380 |
|
| 2017-07-17 11:57:59 |
Launchpad Janitor |
cve linked |
|
2017-7346 |
|
| 2017-07-17 11:57:59 |
Launchpad Janitor |
cve linked |
|
2017-9605 |
|
| 2017-07-17 21:36:59 |
dann frazier |
attachment added |
|
kexec-tools-zesty-verification.log https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1694859/+attachment/4916402/+files/kexec-tools-zesty-verification.log |
|
| 2017-07-17 21:37:16 |
dann frazier |
tags |
qdf2400 verification-needed verification-needed-xenial verification-needed-zesty |
qdf2400 verification-done-zesty verification-needed verification-needed-xenial |
|
| 2017-07-17 22:52:24 |
dann frazier |
attachment added |
|
kexec-tools-xenial-verification.log https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1694859/+attachment/4916441/+files/kexec-tools-xenial-verification.log |
|
| 2017-07-17 22:52:36 |
dann frazier |
tags |
qdf2400 verification-done-zesty verification-needed verification-needed-xenial |
qdf2400 verification-done-xenial verification-done-zesty verification-needed |
|
| 2017-07-17 22:52:45 |
dann frazier |
tags |
qdf2400 verification-done-xenial verification-done-zesty verification-needed |
qdf2400 verification-done verification-done-xenial verification-done-zesty |
|
| 2017-07-20 18:54:29 |
Brian Murray |
makedumpfile (Ubuntu): status |
Confirmed |
Fix Released |
|
| 2017-07-20 18:55:26 |
Brian Murray |
makedumpfile (Ubuntu Zesty): status |
Confirmed |
Fix Released |
|
| 2017-07-20 18:55:42 |
Brian Murray |
makedumpfile (Ubuntu Yakkety): status |
Confirmed |
Won't Fix |
|
| 2017-07-20 18:56:51 |
Brian Murray |
makedumpfile (Ubuntu Xenial): status |
Confirmed |
Fix Committed |
|
| 2017-07-20 18:56:57 |
Brian Murray |
tags |
qdf2400 verification-done verification-done-xenial verification-done-zesty |
qdf2400 verification-done-zesty verification-needed verification-needed-xenial |
|
| 2017-07-20 21:12:08 |
dann frazier |
tags |
qdf2400 verification-done-zesty verification-needed verification-needed-xenial |
qdf2400 verification-done verification-done-xenial verification-done-zesty |
|
| 2017-07-28 00:26:32 |
Launchpad Janitor |
kexec-tools (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2017-07-28 00:26:36 |
Adam Conrad |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2017-07-28 00:36:52 |
Launchpad Janitor |
kexec-tools (Ubuntu Zesty): status |
Fix Committed |
Fix Released |
|
| 2017-08-31 17:03:21 |
Launchpad Janitor |
makedumpfile (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2018-03-01 23:11:59 |
dann frazier |
nominated for series |
|
Ubuntu Artful |
|
| 2018-03-01 23:11:59 |
dann frazier |
bug task added |
|
kexec-tools (Ubuntu Artful) |
|
| 2018-03-01 23:11:59 |
dann frazier |
bug task added |
|
linux (Ubuntu Artful) |
|
| 2018-03-01 23:11:59 |
dann frazier |
bug task added |
|
makedumpfile (Ubuntu Artful) |
|
| 2018-03-01 23:12:39 |
dann frazier |
kexec-tools (Ubuntu Yakkety): status |
In Progress |
Won't Fix |
|
| 2018-03-01 23:17:40 |
dann frazier |
bug watch added |
|
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883899 |
|
| 2018-03-01 23:17:40 |
dann frazier |
bug task added |
|
makedumpfile (Debian) |
|
| 2018-03-01 23:18:08 |
dann frazier |
linux (Ubuntu Artful): status |
New |
Fix Released |
|
| 2018-03-01 23:18:50 |
dann frazier |
makedumpfile (Ubuntu Artful): status |
New |
In Progress |
|
| 2018-03-01 23:18:50 |
dann frazier |
makedumpfile (Ubuntu Artful): assignee |
|
dann frazier (dannf) |
|
| 2018-03-01 23:19:17 |
dann frazier |
kexec-tools (Ubuntu Artful): status |
New |
Fix Released |
|
| 2018-03-03 06:57:07 |
Bug Watch Updater |
makedumpfile (Debian): status |
Unknown |
Fix Released |
|
| 2018-04-12 22:48:48 |
dann frazier |
makedumpfile (Ubuntu Artful): status |
In Progress |
Fix Released |
|
