[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
This bug is awaiting verification that the linux-mtk/5.15.0-1030.34 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-jammy-linux-mtk' to 'verification-done-jammy- linux-mtk'. If the problem still exists, change the tag 'verification- needed-jammy-linux-mtk' to 'verification-failed-jammy-linux-mtk'. 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: kernel-spammed-jammy-linux-mtk-v2 verification-needed-jammy-linux-mtk -- 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: Fix Released Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: Fix Released Status in kexec-tools source package in Jammy: Fix Released Status in linux source package in Jammy: Fix Released Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Released Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. 1) Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. 2) Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. kexec-tools - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either crashdump or kexec functionality. Commit cf977b1af9ec67fab adds code without altering current
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
** Changed in: linux (Ubuntu Jammy) 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: Fix Released Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: Fix Released Status in kexec-tools source package in Jammy: Fix Released Status in linux source package in Jammy: Fix Released Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Released Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. 1) Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. 2) Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. kexec-tools - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either crashdump or kexec functionality. Commit cf977b1af9ec67fab adds code without altering current functionality. Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive it moves the code from vmcore-dmesg.c to elf_info.c so it can be used by other features. kexec-tools - JAMMY, LUNAR, MANTIC: Commit b5a34a20984c is pulled in, it cherry-picks. It changes only arm64 code. It enables kexec to recognise that the reserved kernel may use more than one kernel region. Things could go worng when gatherinng a crashdump. [Other] Commits to backport - MANTIC: kernel 6.3: not affected kexec-tools: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions - LUNAR:
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
This bug is awaiting verification that the linux-xilinx- zynqmp/5.15.0-1024.28 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-jammy-linux-xilinx-zynqmp' to 'verification-done-jammy-linux-xilinx-zynqmp'. If the problem still exists, change the tag 'verification-needed-jammy-linux-xilinx-zynqmp' to 'verification-failed-jammy-linux-xilinx-zynqmp'. 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: kernel-spammed-jammy-linux-xilinx-zynqmp-v2 verification-needed-jammy-linux-xilinx-zynqmp -- 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: Fix Released Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: Fix Released Status in kexec-tools source package in Jammy: Fix Released Status in linux source package in Jammy: Fix Committed Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Released Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. 1) Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. 2) Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. kexec-tools - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either crashdump or kexec
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
This bug has been fixed in Jammy, but not yet marked Fix Released apparently due to an issue with the Launchpad bot (reported to the Launchpad team); leaving as Fix Committed so to trigger when the bot runs again for it. linux (5.15.0-83.92) jammy; urgency=medium * kdump fails on big arm64 systems when offset is not specified (LP: #2024479) - arm64: mm: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef - arm64: kdump: Reimplement crashkernel=X - docs: kdump: Update the crashkernel description for arm64 - arm64: kdump: Do not allocate crash low memory if not needed - arm64/mm: Define defer_reserve_crashkernel() - arm64: kdump: Provide default size when crashkernel=Y, low is not specified - arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones That is also reflected in linux-hwe, see comment #37: > This bug was fixed in the package linux-hwe-5.15 - 5.15.0-83.92~20.04.1 -- 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: Fix Released Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: Fix Released Status in kexec-tools source package in Jammy: Fix Released Status in linux source package in Jammy: Fix Committed Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Released Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. 1) Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. 2) Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. kexec-tools - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
This bug is awaiting verification that the linux-nvidia- tegra-5.15/5.15.0-1017.17~20.04.1 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-focal-linux- nvidia-tegra-5.15' to 'verification-done-focal-linux-nvidia-tegra-5.15'. If the problem still exists, change the tag 'verification-needed-focal- linux-nvidia-tegra-5.15' to 'verification-failed-focal-linux-nvidia- tegra-5.15'. 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: kernel-spammed-focal-linux-nvidia-tegra-5.15-v2 verification-needed-focal-linux-nvidia-tegra-5.15 -- 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: Fix Released Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: Fix Released Status in kexec-tools source package in Jammy: Fix Released Status in linux source package in Jammy: Fix Committed Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Released Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. 1) Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. 2) Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. kexec-tools - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
This bug is awaiting verification that the linux-nvidia-tegra- igx/5.15.0-1004.4 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-jammy-linux-nvidia-tegra- igx' to 'verification-done-jammy-linux-nvidia-tegra-igx'. If the problem still exists, change the tag 'verification-needed-jammy-linux-nvidia- tegra-igx' to 'verification-failed-jammy-linux-nvidia-tegra-igx'. 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: kernel-spammed-jammy-linux-nvidia-tegra-igx-v2 verification-needed-jammy-linux-nvidia-tegra-igx -- 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: Fix Released Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: Fix Released Status in kexec-tools source package in Jammy: Fix Released Status in linux source package in Jammy: Fix Committed Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Released Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. 1) Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. 2) Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. kexec-tools - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
This bug is awaiting verification that the linux-raspi/5.15.0-1038.41 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-jammy-linux-raspi' to 'verification-done-jammy- linux-raspi'. If the problem still exists, change the tag 'verification- needed-jammy-linux-raspi' to 'verification-failed-jammy-linux-raspi'. 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: kernel-spammed-jammy-linux-raspi-v2 verification-needed-jammy-linux-raspi -- 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: Fix Released Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: Fix Released Status in kexec-tools source package in Jammy: Fix Released Status in linux source package in Jammy: Fix Committed Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Released Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. 1) Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. 2) Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. kexec-tools - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either crashdump or kexec functionality. Commit cf977b1af9ec67fab adds code without
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
This bug is awaiting verification that the linux- riscv-5.15/5.15.0-1041.45~20.04.1 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-focal-linux- riscv-5.15' to 'verification-done-focal-linux-riscv-5.15'. If the problem still exists, change the tag 'verification-needed-focal-linux- riscv-5.15' to 'verification-failed-focal-linux-riscv-5.15'. 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: kernel-spammed-focal-linux-riscv-5.15-v2 verification-needed-focal-linux-riscv-5.15 -- 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: Fix Released Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: Fix Released Status in kexec-tools source package in Jammy: Fix Released Status in linux source package in Jammy: Fix Committed Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Released Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. 1) Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. 2) Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. kexec-tools - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either crashdump or kexec functionality.
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
This bug is awaiting verification that the linux-intel- iotg/5.15.0-1039.45 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-jammy-linux-intel-iotg' to 'verification-done-jammy-linux-intel-iotg'. If the problem still exists, change the tag 'verification-needed-jammy-linux-intel-iotg' to 'verification-failed-jammy-linux-intel-iotg'. 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: kernel-spammed-jammy-linux-intel-iotg-v2 verification-needed-jammy-linux-intel-iotg -- 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: Fix Released Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: Fix Released Status in kexec-tools source package in Jammy: Fix Released Status in linux source package in Jammy: Fix Committed Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Released Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. 1) Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. 2) Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. kexec-tools - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either crashdump or kexec functionality. Commit
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
This bug is awaiting verification that the linux-nvidia- tegra/5.15.0-1017.17 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-jammy-linux-nvidia-tegra' to 'verification-done-jammy-linux-nvidia-tegra'. If the problem still exists, change the tag 'verification-needed-jammy-linux-nvidia-tegra' to 'verification-failed-jammy-linux-nvidia-tegra'. 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: kernel-spammed-jammy-linux-nvidia-tegra-v2 verification-needed-jammy-linux-nvidia-tegra -- 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: Fix Released Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: Fix Released Status in kexec-tools source package in Jammy: Fix Released Status in linux source package in Jammy: Fix Committed Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Released Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. 1) Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. 2) Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. kexec-tools - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either crashdump or kexec functionality.
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
This bug was fixed in the package linux-hwe-5.15 - 5.15.0-83.92~20.04.1 --- linux-hwe-5.15 (5.15.0-83.92~20.04.1) focal; urgency=medium * focal/linux-hwe-5.15: 5.15.0-83.92~20.04.1 -proposed tracker (LP: #2030420) [ Ubuntu: 5.15.0-83.92 ] * jammy/linux: 5.15.0-83.92 -proposed tracker (LP: #2031132) * libgnutls report "trap invalid opcode" when trying to install packages over https (LP: #2031093) - [Config]: disable CONFIG_GDS_FORCE_MITIGATION [ Ubuntu: 5.15.0-81.90 ] * jammy/linux: 5.15.0-81.90 -proposed tracker (LP: #2030422) * Packaging resync (LP: #1786013) - [Packaging] resync update-dkms-versions helper - [Packaging] resync getabis - debian/dkms-versions -- update from kernel-versions (main/2023.08.07) * CVE-2022-40982 - x86/mm: Initialize text poking earlier - x86/mm: fix poking_init() for Xen PV guests - x86/mm: Use mm_alloc() in poking_init() - mm: Move mm_cachep initialization to mm_init() - init: Provide arch_cpu_finalize_init() - x86/cpu: Switch to arch_cpu_finalize_init() - ARM: cpu: Switch to arch_cpu_finalize_init() - sparc/cpu: Switch to arch_cpu_finalize_init() - um/cpu: Switch to arch_cpu_finalize_init() - init: Remove check_bugs() leftovers - init: Invoke arch_cpu_finalize_init() earlier - init, x86: Move mem_encrypt_init() into arch_cpu_finalize_init() - x86/init: Initialize signal frame size late - x86/fpu: Remove cpuinfo argument from init functions - x86/fpu: Mark init functions __init - x86/fpu: Move FPU initialization into arch_cpu_finalize_init() - x86/xen: Fix secondary processors' FPU initialization - x86/speculation: Add Gather Data Sampling mitigation - x86/speculation: Add force option to GDS mitigation - x86/speculation: Add Kconfig option for GDS - KVM: Add GDS_NO support to KVM - Documentation/x86: Fix backwards on/off logic about YMM support - [Config]: Enable CONFIG_ARCH_HAS_CPU_FINALIZE_INIT and CONFIG_GDS_FORCE_MITIGATION * CVE-2023-3609 - net/sched: cls_u32: Fix reference counter leak leading to overflow * CVE-2023-21400 - io_uring: ensure IOPOLL locks around deferred work * CVE-2023-4015 - netfilter: nf_tables: add NFT_TRANS_PREPARE_ERROR to deal with bound set/chain - netfilter: nf_tables: unbind non-anonymous set if rule construction fails - netfilter: nf_tables: skip immediate deactivate in _PREPARE_ERROR * CVE-2023-3995 - netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID * CVE-2023-3777 - netfilter: nf_tables: skip bound chain on rule flush * losetup with mknod fails on jammy with kernel 5.15.0-69-generic (LP: #2015400) - loop: do not enforce max_loop hard limit by (new) default * Include the MAC address pass through function on RTL8153DD-CG (LP: #2020295) - r8152: add USB device driver for config selection * Jammy update: v5.15.116 upstream stable release (LP: #2029401) - RDMA/bnxt_re: Fix the page_size used during the MR creation - RDMA/efa: Fix unsupported page sizes in device - RDMA/hns: Fix base address table allocation - RDMA/hns: Modify the value of long message loopback slice - dmaengine: at_xdmac: Move the free desc to the tail of the desc list - dmaengine: at_xdmac: fix potential Oops in at_xdmac_prep_interleaved() - RDMA/bnxt_re: Fix a possible memory leak - RDMA/bnxt_re: Fix return value of bnxt_re_process_raw_qp_pkt_rx - iommu/rockchip: Fix unwind goto issue - iommu/amd: Don't block updates to GATag if guest mode is on - dmaengine: pl330: rename _start to prevent build error - riscv: Fix unused variable warning when BUILTIN_DTB is set - net/mlx5: fw_tracer, Fix event handling - net/mlx5e: Don't attach netdev profile while handling internal error - net: mellanox: mlxbf_gige: Fix skb_panic splat under memory pressure - netrom: fix info-leak in nr_write_internal() - af_packet: Fix data-races of pkt_sk(sk)->num. - amd-xgbe: fix the false linkup in xgbe_phy_status - mtd: rawnand: ingenic: fix empty stub helper definitions - RDMA/irdma: Add SW mechanism to generate completions on error - RDMA/irdma: Prevent QP use after free - RDMA/irdma: Fix Local Invalidate fencing - af_packet: do not use READ_ONCE() in packet_bind() - tcp: deny tcp_disconnect() when threads are waiting - tcp: Return user_mss for TCP_MAXSEG in CLOSE/LISTEN state if user_mss set - net/sched: sch_ingress: Only create under TC_H_INGRESS - net/sched: sch_clsact: Only create under TC_H_CLSACT - net/sched: Reserve TC_H_INGRESS (TC_H_CLSACT) for ingress (clsact) Qdiscs - net/sched: Prohibit regrafting ingress or clsact Qdiscs - net: sched: fix NULL pointer dereference in mq_attach - net/netlink: fix NETLINK_LIST_MEMBERSHIPS length report - udp6: Fix race condition in udp6_sendmsg & connect - net/mlx5e: Fix error
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
The kernel changes are Fix Committed in the Azure kernel packages, and should land slightly earlier than the Generic kernel packages. linux-azure (5.15.0-1043.50) jammy-proposed linux-azure-5.15 (5.15.0-1043.50~20.04.1) focal-proposed -- 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: Fix Released Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: In Progress Status in kexec-tools source package in Jammy: Fix Released Status in linux source package in Jammy: In Progress Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Released Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. 1) Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. 2) Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. kexec-tools - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either crashdump or kexec functionality. Commit cf977b1af9ec67fab adds code without altering current functionality. Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive it moves the code from vmcore-dmesg.c to elf_info.c so it can be used by other features. kexec-tools - JAMMY, LUNAR, MANTIC: Commit b5a34a20984c is pulled in, it cherry-picks. It changes only arm64 code. It enables kexec to recognise that the reserved kernel may use more than one kernel region. Things could go worng when gatherinng a crashdump. [Other] Commits to backport - MANTIC: kernel
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
This bug was fixed in the package kexec-tools - 1:2.0.18-1ubuntu1.1 --- kexec-tools (1:2.0.18-1ubuntu1.1) focal; urgency=medium * Support more than one crash kernel regions for arm64 (LP: #2024479) - d/p/lp2024479-0001-util_lib-Add-functionality-to-read-elf-notes.patch - d/p/lp2024479-0002-arm64-Add-support-to-read-PHYS_OFFSET-from-kcore-pt_.patch - d/p/lp2024479-0003-kexec-add-variant-helper-functions-for-handling-memo.patch - d/p/lp2024479-0004-arm64-kexec-allocate-memory-space-avoiding-reserved-.patch - d/p/lp2024479-0005-arm64-kdump-deal-with-a-lot-of-resource-entries-in-p.patch - d/p/lp2024479-0006-arm64-support-more-than-one-crash-kernel-regions.patch -- Ioanna Alifieraki Mon, 03 Jul 2023 16:29:58 +0300 -- 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: Fix Released Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: In Progress Status in kexec-tools source package in Jammy: Fix Released Status in linux source package in Jammy: In Progress Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Released Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. 1) Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. 2) Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. kexec-tools - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either crashdump or kexec functionality. Commit cf977b1af9ec67fab adds code without
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
This bug was fixed in the package kexec-tools - 1:2.0.22-2ubuntu3.1 --- kexec-tools (1:2.0.22-2ubuntu3.1) lunar; urgency=medium * Support more than one crash kernel regions for arm64 (LP: #2024479) - d/p/lp2024479-arm64-support-more-than-one-crash-kernel-regions.patch -- Ioanna Alifieraki Mon, 03 Jul 2023 15:28:52 +0300 ** Changed in: kexec-tools (Ubuntu Lunar) Status: Fix Committed => Fix Released ** Changed in: kexec-tools (Ubuntu Jammy) 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: Fix Released Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: In Progress Status in kexec-tools source package in Jammy: Fix Released Status in linux source package in Jammy: In Progress Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Released Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. 1) Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. 2) Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. kexec-tools - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either crashdump or kexec functionality. Commit cf977b1af9ec67fab adds code without altering current functionality. Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive it moves the code from vmcore-dmesg.c to elf_info.c so it can be used by other features. kexec-tools - JAMMY, LUNAR, MANTIC: Commit
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
This bug was fixed in the package kexec-tools - 1:2.0.22-2ubuntu2.22.04.1 --- kexec-tools (1:2.0.22-2ubuntu2.22.04.1) jammy; urgency=medium * Support more than one crash kernel regions for arm64 (LP: #2024479) - d/p/lp2024479-arm64-support-more-than-one-crash-kernel-regions.patch -- Ioanna Alifieraki Mon, 03 Jul 2023 15:34:26 +0300 ** Changed in: kexec-tools (Ubuntu Focal) 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: Fix Released Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: In Progress Status in kexec-tools source package in Jammy: Fix Released Status in linux source package in Jammy: In Progress Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Released Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. 1) Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. 2) Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. kexec-tools - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either crashdump or kexec functionality. Commit cf977b1af9ec67fab adds code without altering current functionality. Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive it moves the code from vmcore-dmesg.c to elf_info.c so it can be used by other features. kexec-tools - JAMMY, LUNAR, MANTIC: Commit b5a34a20984c is pulled in, it cherry-picks. It changes only arm64 code.
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
# VERIFICATION FOCAL kexec-tools & hwe kernel 5.15 For this set of verification we test both kexec-tools and kernel 5.15 from proposed.. 1) On a focal machine with 184G of memory, installed kexec-tools and hwe kernel 5.15 from proposed and triggered a crash. Crashdump file is generated successfully. root@bigfossa:/var/crash# uname -rv 5.15.0-1043-azure #50~20.04.1-Ubuntu SMP Wed Jul 19 16:39:01 UTC 2023 root@bigfossa:/var/crash# dpkg -l | grep kexec-tools ii kexec-tools 1:2.0.18-1ubuntu1.1 arm64tools to support fast kexec reboots root@bigfossa:/var/crash# cat /etc/default/grub.d/kdump-tools.cfg GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" root@bigfossa:/var/crash# ls 202307211020/ dmesg.202307211020 dump.202307211020 root@bigfossa:/var/crash# 2) On a jammy machine with 4G of memory, installed kexec-tools and hwe kernel 5.15 from proposed and triggered a crash. Crashdump file is generated successfully. root@smallfossa:/var/crash# uname -rv 5.15.0-1043-azure #50~20.04.1-Ubuntu SMP Wed Jul 19 16:39:01 UTC 2023 root@smallfossa:/var/crash# dpkg -l | grep kexec-tools ii kexec-tools 1:2.0.18-1ubuntu1.1 arm64tools to support fast kexec reboots root@smallfossa:/var/crash# cat /etc/default/grub.d/kdump-tools.cfg GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=320M" root@smallfossa:/var/crash# ls 202307241309/ dmesg.202307241309 dump.202307241309 root@smallfossa:/var/crash# ** Tags removed: verification-needed verification-needed-focal ** Tags added: verification-done verification-done-focal -- 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: Fix Committed Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: In Progress Status in kexec-tools source package in Jammy: Fix Committed Status in linux source package in Jammy: In Progress Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Committed Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. 1) Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. 2) Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal).
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
# VERIFICATION FOCAL kexec-tools & kernel 5.4 For this set of verifications we will test the kexec-tools in -proposed with the 5.4 kernel. The 5.4 kernel will not work in cases where the crashkernel need to be allocated in both low and high memory because we have not patched it. Therefore the tests are done only on a test machine with little memory. The purpose is to confirm that kexec-tools in -proposed does not introduce regressions. 1) Not applicable. 2) On a focal machine with 4G of memory, running 5.4 kernel installed kexec-tools from proposed and triggered a crash. Crashdump file is generated successfully. root@smallfossa:/var/crash# uname -rv 5.4.0-1113-azure #119-Ubuntu SMP Wed Jul 19 16:08:59 UTC 2023 root@smallfossa:/var/crash# dpkg -l | grep kexec-tools ii kexec-tools 1:2.0.18-1ubuntu1.1 arm64tools to support fast kexec reboots root@smallfossa:/var/crash# cat /etc/default/grub.d/kdump-tools.cfg GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=320M" root@smallfossa:/var/crash# ls 202307241318/ dmesg.202307241318 dump.202307241318 root@smallfossa:/var/crash# -- 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: Fix Committed Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: In Progress Status in kexec-tools source package in Jammy: Fix Committed Status in linux source package in Jammy: In Progress Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Committed Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. 1) Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. 2) Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
# VERIFICATION JAMMY kexec-tools & kernel 5.15 1) On a jammy machine with 184G of memory, installed kexec-tools and kernel 5.15 from proposed and triggered a crash. Crashdump file is generated successfully. root@bigjelly:/var/crash# uname -rv 5.15.0-1043-azure #50-Ubuntu SMP Tue Jul 18 19:20:09 UTC 2023 root@bigjelly:/var/crash# dpkg -l | grep kexec-tools ii kexec-tools 1:2.0.22-2ubuntu2.22.04.1 arm64tools to support fast kexec reboots root@bigjelly:/var/crash# cat /etc/default/grub.d/kdump-tools.cfg GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" root@bigjelly:/var/crash# ls 202307201513/ dmesg.202307201513 dump.202307201513 root@bigjelly:/var/crash# 2) On a jammy machine with 4G of memory, installed kexec-tools and kernel 5.15 from proposed and triggered a crash. Crashdump file is generated successfully. root@smalljelly:/var/crash# uname -rv 5.15.0-1043-azure #50-Ubuntu SMP Tue Jul 18 19:20:09 UTC 2023 root@smalljelly:/var/crash# dpkg -l | grep kexec-tools ii kexec-tools 1:2.0.22-2ubuntu2.22.04.1 arm64tools to support fast kexec reboots root@smalljelly:/var/crash# cat /etc/default/grub.d/ 40-force-partuuid.cfg 50-cloudimg-settings.cfg init-select.cfg kdump-tools.cfg root@smalljelly:/var/crash# cat /etc/default/grub.d/kdump-tools.cfg GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=320M" root@smalljelly:/var/crash# ls 202307210759/ dmesg.202307210759 dump.202307210759 root@smalljelly:/var/crash# ** Tags removed: verification-needed-jammy ** Tags added: verification-done-jammy -- 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: Fix Committed Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: In Progress Status in kexec-tools source package in Jammy: Fix Committed Status in linux source package in Jammy: In Progress Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Committed Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. 1) Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. 2) Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
** Description changed: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. - - Failing scenario (crashkernel >= 4G, without offset "@"): + 1) Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. - - Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') + 2) Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. kexec-tools - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either crashdump or kexec functionality. Commit cf977b1af9ec67fab adds code without altering current functionality. Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive it moves the code from vmcore-dmesg.c to elf_info.c so it can be used by other features. kexec-tools - JAMMY, LUNAR, MANTIC: Commit b5a34a20984c is pulled in, it cherry-picks. It changes only arm64 code. It enables kexec to recognise that the reserved kernel may use more than one kernel region. Things could go worng when gatherinng a crashdump. [Other] Commits to backport - MANTIC: kernel 6.3: not affected kexec-tools: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions - LUNAR: kernel 6.2: not affected kexec-tools: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions - KINETIC: WON'T FIX Kinetic won't be fixed as it is EOL soon. - JAMMY: kernel (5.15 kernel): a9ae89df737756d92f0e14873339cf393f7f7eb0 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones a149cf00b158e1793a8dd89ca492379c366300d2 arm64: kdump: Provide default size when crashkernel=Y,low is not specified 4890cc18f94979b406f95708f8cb238eb2d0e5a9 arm64/mm: Define defer_reserve_crashkernel() 8f0f104e2ab6eed4cad3b111dc206f843bda43ea arm64: kdump: Do not allocate crash low memory if not needed 5832f1ae50600ac6b2b6d00cfef42d33a9473f06 docs: kdump: Update the crashkernel description for arm64 944a45abfabc171fd121315ff0d5e62b11cb5d6f arm64: kdump: Reimplement crashkernel=X
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
# VERIFICATION LUNAR kexec-tools On a lunar machine with 184G of memory, running 6.2 kernel install kexec-tools from proposed and triggered a crash. Crashdump file is generated successfully. root@biglunar:/var/crash# uname -rv 6.2.0-1005-azure #5-Ubuntu SMP Thu Jun 1 23:59:56 UTC 2023 root@biglunar:/var/crash# dpkg -l | grep kexec-tools ii kexec-tools1:2.0.22-2ubuntu3.1 arm64tools to support fast kexec reboots root@biglunar:/var/crash# cat /etc/default/grub grubgrub.d/ root@biglunar:/var/crash# cat /etc/default/grub.d/kdump-tools.cfg GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" root@biglunar:/var/crash# ls 202307201417/ dmesg.202307201417 dump.202307201417 root@biglunar:/var/crash# ** Tags removed: verification-needed-lunar ** Tags added: verification-done-lunar -- 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: Fix Committed Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: In Progress Status in kexec-tools source package in Jammy: Fix Committed Status in linux source package in Jammy: In Progress Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Committed Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. - Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. - Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. kexec-tools - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
Hello Ioanna, or anyone else affected, Accepted kexec-tools into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/kexec- tools/1:2.0.18-1ubuntu1.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, what testing has been performed on the package and change the tag from verification-needed- focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-focal. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: kexec-tools (Ubuntu Focal) Status: In Progress => Fix Committed ** Tags added: verification-needed-focal -- 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: Fix Committed Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: In Progress Status in kexec-tools source package in Jammy: Fix Committed Status in linux source package in Jammy: In Progress Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Committed Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. - Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. - Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
This bug is awaiting verification that the linux-azure/5.15.0-1043.50 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-jammy' to 'verification-done-jammy'. If the problem still exists, change the tag 'verification-needed-jammy' to 'verification-failed-jammy'. 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: kernel-spammed-jammy-linux-azure -- 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: In Progress Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: In Progress Status in kexec-tools source package in Jammy: Fix Committed Status in linux source package in Jammy: In Progress Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Committed Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. - Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. - Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. kexec-tools - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either crashdump or kexec functionality. Commit cf977b1af9ec67fab adds code without altering current functionality. Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
For documentation purposes: the riscv64 build fails on jammy/lunar-proposed, which is not a regression; that is since/on the jammy/lunar-release pockets. -- 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: In Progress Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: In Progress Status in kexec-tools source package in Jammy: Fix Committed Status in linux source package in Jammy: In Progress Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Committed Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. - Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. - Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. kexec-tools - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either crashdump or kexec functionality. Commit cf977b1af9ec67fab adds code without altering current functionality. Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive it moves the code from vmcore-dmesg.c to elf_info.c so it can be used by other features. kexec-tools - JAMMY, LUNAR, MANTIC: Commit b5a34a20984c is pulled in, it cherry-picks. It changes only arm64 code. It enables kexec to recognise that the reserved kernel may use more than one kernel region. Things could go worng when gatherinng a crashdump. [Other] Commits to backport - MANTIC: kernel 6.3: not affected kexec-tools: b5a34a20984c4ad27cc5054d9957af8130b42a50
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
** Changed in: kexec-tools (Ubuntu Focal) Status: Incomplete => 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: In Progress Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: In Progress Status in kexec-tools source package in Jammy: Fix Committed Status in linux source package in Jammy: In Progress Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Committed Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. - Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. - Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. kexec-tools - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either crashdump or kexec functionality. Commit cf977b1af9ec67fab adds code without altering current functionality. Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive it moves the code from vmcore-dmesg.c to elf_info.c so it can be used by other features. kexec-tools - JAMMY, LUNAR, MANTIC: Commit b5a34a20984c is pulled in, it cherry-picks. It changes only arm64 code. It enables kexec to recognise that the reserved kernel may use more than one kernel region. Things could go worng when gatherinng a crashdump. [Other] Commits to backport - MANTIC: kernel 6.3: not affected kexec-tools: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions - LUNAR:
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
Hi Steve, Thanks for reviewing! > Is this driven by user demand on focal? Yes, this is driven by a support case from Azure (kdump error on Arm64 VM w/ 48 vCPUs 192 GiB RAM). > Was this a problem in practice when focal was released, > or has it become a problem more recently It seems that support for arm64 on Azure started on 2022, ~2 years after Focal release, as the first arm64 build of the linux-azure kernel package is 5.4.0-1075.78 (Apr 2022). https://launchpad.net/ubuntu/focal/+source/linux-azure https://launchpad.net/ubuntu/+source/linux-azure/5.4.0-1074.77 (amd64 only) https://launchpad.net/ubuntu/+source/linux-azure/5.4.0-1075.78 (amd64 and arm64) > I want to make sure we're not just SRUing it here in an effort to be "completionist". That's certainly understandable. In this case, no; the patches are down to Focal as that is the release where the bug/support case were reported, and would ideally be fixed on, if at all possible. Hope this helps. Thanks! -- 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: In Progress Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: In Progress Status in kexec-tools source package in Jammy: Fix Committed Status in linux source package in Jammy: In Progress Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Committed Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. - Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. - Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. kexec-tools - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
The patch for focal is quite a bit larger than for jammy and lunar, and I question whether it's really needed. Is this driven by user demand on focal? Was this a problem in practice when focal was released, or has it become a problem more recently as a result of growing memory usage by the kernel? Since this introduces greater risk and requires more review effort from the SRU team, I want to make sure we're not just SRUing it here in an effort to be "completionist". ** Changed in: kexec-tools (Ubuntu Focal) Status: In Progress => Incomplete -- 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: Incomplete Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: In Progress Status in kexec-tools source package in Jammy: Fix Committed Status in linux source package in Jammy: In Progress Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Committed Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. - Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. - Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. kexec-tools - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either crashdump or kexec functionality. Commit cf977b1af9ec67fab adds code without altering current functionality. Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive it moves the code from vmcore-dmesg.c to elf_info.c so it can be used by other features. kexec-tools
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
Hello Ioanna, or anyone else affected, Accepted kexec-tools into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/kexec- tools/1:2.0.22-2ubuntu2.22.04.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, what testing has been performed on the package and change the tag from verification-needed- jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-jammy. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: kexec-tools (Ubuntu Jammy) Status: In Progress => Fix Committed ** Tags added: verification-needed-jammy -- 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: In Progress Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: In Progress Status in kexec-tools source package in Jammy: Fix Committed Status in linux source package in Jammy: In Progress Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Committed Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. - Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. - Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
Hello Ioanna, or anyone else affected, Accepted kexec-tools into lunar-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/kexec- tools/1:2.0.22-2ubuntu3.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, what testing has been performed on the package and change the tag from verification-needed- lunar to verification-done-lunar. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-lunar. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: kexec-tools (Ubuntu Lunar) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-lunar -- 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: In Progress Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: In Progress Status in kexec-tools source package in Jammy: In Progress Status in linux source package in Jammy: In Progress Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: Fix Committed Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. - Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. - Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
Hi Jo,
Thanks for the debdiffs.
Lunar and Jammy (both: 1 patch) look good, just removed '0001' from
.patch.
Focal has 6 patches and required more attention/changes (which I adjusted),
and patches look good (some notes below for documentation/other reviewers).
The (updated) debdiffs built correctly on ppa:mfo/lp2024479 on supported
architectures (amd64, arm64, armhf, ppc64el, s390x) and I'm confident on
your testing to be performed during -proposed verification.
So, uploaded to F/J/L.
Thanks,
Mauricio
...
Focal:
1) all Origin: links had wrong commit IDs; fixed.
2) there are commits to fix 3 different things, IIUIC,
all of which are needed for big arm64 systems:
(patches 1-2) phys_offset on large memory systems;
(patches 3-5) many memory regions in /proc/iomem;
(patch 6) split / memory regions for crash kernel;
3) patch 1 is mostly a big code movement, which I followed,
and the few small changes in existing functions are for
the purpose described (and are additions, not changes).
4) patch 2 adds code and hooks it into existing code
5) patch 3 simplifies the function call path, which is OK,
and does a more significant logic change, but it still
should perform the same thing (parse /proc/iomem format,
which didn't change), and has no fixup commits.
6) patch 4 adds helpers for patches 3 and 5.
7) btw, patches 3/4 order is swapped (3 deps on 4); fixed.
8) patch 5 uses the helpers to change some existing code
from static to dynamic allocation.
9) patch 6 (added to J/L/M) too, similarly, for the number
of crash kernel / usable memory regions.
Fix-up commits: none strictly required.
---
I checked for newer commits (after 1st) in the modified files:
(cat lp2024479_focal-v2.debdiff | grep '^+--- a/' | cut -d/ -f2- | sort -u)
$ git log --oneline f4ce0706d9574aecb7d4aa9af7208a1bc9b6afb4..origin/master -- \
kexec/arch/arm64/{kexec,crashdump}-arm64.{c,h} \
kexec/mem_regions.{c,h} \
util_lib/Makefile \
vmcore-dmesg/Makefile \
vmcore-dmesg/vmcore-dmesg.c
Only 4 commits were applicable to these code changes, AFAICT.
There are 3 cleanup/style/optional, no functional impact:
- commit 545c811050a3 ("Cleanup: remove the read_elf_kcore()")
- commit 14ad054e7baa ("Fix an error definition about the variable 'fname'")
- commit a7c4cb8e9985 ("Cleanup: move it back from util_lib/elf_info.c")
There is 1 which is more serious, but does not impact Ubuntu kernels,
since do not use 52-bit (but 48-) virtual address space with M/L/J/F:
- commit 67ea2d99e135 ("arm64: make phys_offset signed")
(... phys_offset can be negative if running 52-bits kernel on 48-bits
hardware ...)
mantic:
$ git grep -r ARM64_VA_BITS origin/master-next -- debian.master/config
| grep -e "'y'" -e ARM64_VA_BITS_52
<...>:CONFIG_ARM64_VA_BITS_48 policy<{'arm64':
'y'}>
<...>:CONFIG_ARM64_VA_BITS_52
policy<{'arm64-generic-64k': 'n'}>
lunar:
$ git grep -r ARM64_VA_BITS origin/master-next -- debian.master/config
| grep -e "'y'" -e ARM64_VA_BITS_52
<...>:CONFIG_ARM64_VA_BITS_48 policy<{'arm64':
'y'}>
<...>:CONFIG_ARM64_VA_BITS_52
policy<{'arm64-generic-64k': 'n'}>
jammy:
$ git grep -r ARM64_VA_BITS origin/master-next -- debian.master/config
| grep -e "'y'" -e ARM64_VA_BITS_52
<...>:CONFIG_ARM64_VA_BITS_48 policy<{'arm64':
'y'}>
<...>:CONFIG_ARM64_VA_BITS_52
policy<{'arm64-generic-64k': 'n', 'arm64-lowlatency-64k': 'n'}>
focal:
$ git grep -r ARM64_VA_BITS origin/master-next -- debian.master/config
| grep -e "'y'" -e ARM64_VA_BITS_52
<...>:CONFIG_ARM64_VA_BITS_48 policy<{'arm64':
'y'}>
--
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/2024479
Title:
kdump fails on big arm64 systems when offset is not specified
Status in kexec-tools package in Ubuntu:
Fix Released
Status in linux package in Ubuntu:
Invalid
Status in linux-hwe-5.15 package in Ubuntu:
Invalid
Status in kexec-tools source package in Focal:
In Progress
Status in linux source package in Focal:
Won't Fix
Status in linux-hwe-5.15 source package in Focal:
In Progress
Status in kexec-tools source package in Jammy:
In Progress
Status in linux source package in Jammy:
In Progress
Status in linux-hwe-5.15 source package in Jammy:
Invalid
Status in kexec-tools source package in Kinetic:
Won't Fix
Status in linux source package in Kinetic:
Won't Fix
Status in linux-hwe-5.15 source package in Kinetic:
Invalid
Status in kexec-tools source package in Lunar:
In Progress
Status in kexec-tools source package in Mantic:
Fix Released
Bug description:
[Impact]
kdump fails on arm64, on machines with a lot of memory when offset is not
[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified
** Summary changed: - kdump fails on arm64 when offset is not specified + kdump fails on big arm64 systems when offset is not specified -- 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/2024479 Title: kdump fails on big arm64 systems when offset is not specified Status in kexec-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in linux-hwe-5.15 package in Ubuntu: Invalid Status in kexec-tools source package in Focal: In Progress Status in linux source package in Focal: Won't Fix Status in linux-hwe-5.15 source package in Focal: In Progress Status in kexec-tools source package in Jammy: In Progress Status in linux source package in Jammy: In Progress Status in linux-hwe-5.15 source package in Jammy: Invalid Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in linux-hwe-5.15 source package in Kinetic: Invalid Status in kexec-tools source package in Lunar: In Progress Status in kexec-tools source package in Mantic: Fix Released Bug description: [Impact] kdump fails on arm64, on machines with a lot of memory when offset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel region. [Fix] To address this issue the following upstream commits are needed: - From the kernel side: commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified - From kexec-tools: commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the Focal 5.15 hwe kernel (from Jammy) will be fixed. [Test Plan] You need an arm64 machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump, configure the crash kernel size, and trigger a crash. - Failing scenario (crashkernel >= 4G, without offset "@"): It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. - Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G') This must continue to work with the new patches (ie, no regressions), including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on Focal). [Regression Potential] KERNEL 5.15 - Jammy (and Focal via the HWE kernel): To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. kexec-tools - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either crashdump or kexec functionality. Commit cf977b1af9ec67fab adds code without altering current functionality. Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive it moves the code from vmcore-dmesg.c to elf_info.c so it can be used by other features. kexec-tools - JAMMY, LUNAR, MANTIC: Commit b5a34a20984c is pulled in, it cherry-picks. It changes only arm64 code. It enables kexec to recognise that the reserved kernel may use more than one kernel region. Things could go worng when gatherinng a crashdump. [Other] Commits to backport - MANTIC: kernel 6.3: not affected kexec-tools: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more
