On 10/14/22 11:29 AM, Catalin Marinas wrote:
On Thu, Oct 13, 2022 at 06:46:35PM +0800, Baoquan He wrote:
On 10/06/22 at 09:55am, john.p.donne...@oracle.com wrote:
What is the progress of this series ?
Without this patch set we are seeing larger crashkernel=896M failures on
Arm with Linux-6.0
On 8/1/22 9:47 PM, Leizhen (ThunderTown) wrote:
On 2022/8/1 16:20, Baoquan He wrote:
Hi Catalin,
On 07/11/22 at 05:03pm, Zhen Lei wrote:
v2 --> v3:
1. Discard patch 3 in v2, a cleanup patch.
v1 --> v2:
1. Update the commit message of Patch 1, explicitly indicates that
"crashkernel=X,high"
On 1/24/22 2:47 AM, Zhen Lei wrote:
From: Chen Zhou
For arm64, the behavior of crashkernel=X has been changed, which
tries low allocation in DMA zone and fall back to high allocation
if it fails.
We can also use "crashkernel=X,high" to select a high region above
DMA zone, which also tries to a
On 1/24/22 2:47 AM, Zhen Lei wrote:
From: Chen Zhou
When reserving crashkernel in high memory, some low memory is reserved
for crash dump kernel devices and never mapped by the first kernel.
This memory range is advertised to crash dump kernel via DT property
under /chosen,
linux,usabl
On 1/24/22 2:47 AM, Zhen Lei wrote:
From: Chen Zhou
There are following issues in arm64 kdump:
1. We use crashkernel=X to reserve crashkernel below 4G, which
will fail when there is no enough low memory.
2. If reserving crashkernel above 4G, in this case, crash dump
kernel will boot failure bec
On 1/24/22 2:47 AM, Zhen Lei wrote:
From: Chen Zhou
Introduce macro CRASH_ALIGN for alignment, macro CRASH_ADDR_LOW_MAX
for upper bound of low crash memory, macro CRASH_ADDR_HIGH_MAX for
upper bound of high crash memory, use macros instead.
Signed-off-by: Chen Zhou
Signed-off-by: Zhen Lei
Te
On 1/24/22 2:47 AM, Zhen Lei wrote:
insert_resource() traverses the subtree layer by layer from the root node
until a proper location is found. Compared with request_resource(), the
parent node does not need to be determined in advance.
In addition, move the insertion of node 'crashk_res' into f
On 12/23/21 3:44 AM, Baoquan He wrote:
**Problem observed:
On x86_64, when crash is triggered and entering into kdump kernel, page
allocation failure can always be seen.
-
DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations
swapper/0: page alloc
On 12/28/21 7:26 AM, Zhen Lei wrote:
From: Chen Zhou
Move the definition and declaration of global variable crashk[_low]_res
from kexec module to crash_core module, in preparation of adding generic
reserve_crashkernel_mem[_low]() to crash_core.c, the latter refers to
variable crashk[_low]_res.
On 12/28/21 7:26 AM, Zhen Lei wrote:
Add macro CRASH_BASE_ALIGN to indicate the alignment for crash kernel
fixed region, in preparation for making partial implementation of
reserve_crashkernel[_low]() generic.
Signed-off-by: Zhen Lei
>
Acked-by: John Donnelly
---
arch/x86/kernel/setup.c
On 12/28/21 7:26 AM, Zhen Lei wrote:
Delete confusing parameters 'system_ram' and 'crash_base' of
parse_crashkernel_{high|low}(), they are only needed by the case of
"crashkernel=X@[offset]".
Signed-off-by: Zhen Lei
>
Acked-by: John Donnelly
---
kernel/crash_core.c | 21 ++---
On 12/28/21 7:26 AM, Zhen Lei wrote:
Make parse_crashkernel_{high|low}() static, they are only referenced by
parse_crashkernel_high_low() in the same file. The latter is recommended.
Signed-off-by: Zhen Lei
>
Acked-by: John Donnelly
---
include/linux/crash_core.h | 4
kernel/crash_
On 12/28/21 7:26 AM, Zhen Lei wrote:
Use parse_crashkernel_high_low() to bring the parsing of
"crashkernel=X,high" and the parsing of "crashkernel=Y,low" together, they
are strongly dependent, make code logic clear and more readable.
Suggested-by: Borislav Petkov
Signed-off-by: Zhen Lei
>
Ack
On 12/28/21 7:26 AM, Zhen Lei wrote:
The bootup command line option crashkernel=Y,low is valid only when
crashkernel=X,high is specified. Putting their parsing into a separate
function makes the code logic clearer and easier to understand the strong
dependencies between them.
Signed-off-by: Zhen
On 12/23/21 3:44 AM, Baoquan He wrote:
In some places of the current kernel, it assumes that dma zone must have
managed pages if CONFIG_ZONE_DMA is enabled. While this is not always true.
E.g in kdump kernel of x86_64, only low 1M is presented and locked down
at very early stage of boot, so that
On 12/23/21 3:44 AM, Baoquan He wrote:
In kdump kernel of x86_64, page allocation failure is observed:
kworker/u2:2: page allocation failure: order:0,
mode:0xcc1(GFP_KERNEL|GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
CPU: 0 PID: 55 Comm: kworker/u2:2 Not tainted 5.16.0-rc4+ #5
Hardw
On 12/23/21 3:44 AM, Baoquan He wrote:
Currently three dma atomic pools are initialized as long as the relevant
kernel codes are built in. While in kdump kernel of x86_64, this is not
right when trying to create atomic_pool_dma, because there's no managed
pages in DMA zone. In the case, DMA zone
On 12/14/21 10:31 AM, Christoph Hellwig wrote:
On Mon, Dec 13, 2021 at 08:27:12PM +0800, Baoquan He wrote:
Dma-kmalloc will be created as long as CONFIG_ZONE_DMA is enabled.
However, it will fail if DMA zone has no managed pages. The failure
can be seen in kdump kernel of x86_64 as below:
Plea
On 12/10/21 12:55 AM, Zhen Lei wrote:
There are following issues in arm64 kdump:
1. We use crashkernel=X to reserve crashkernel below 4G, which
will fail when there is no enough low memory.
2. If reserving crashkernel above 4G, in this case, crash dump
kernel will boot failure because there is no
On 12/10/21 12:55 AM, Zhen Lei wrote:
From: Chen Zhou
For arm64, the behavior of crashkernel=X has been changed, which
tries low allocation in DMA zone and fall back to high allocation
if it fails.
We can also use "crashkernel=X,high" to select a high region above
DMA zone, which also tries to
On 12/10/21 12:55 AM, Zhen Lei wrote:
Currently, we parse the "linux,usable-memory-range" property in
early_init_dt_scan_chosen(), to obtain the specified memory range of the
crash kernel. We then reserve the required memory after
early_init_dt_scan_memory() has identified all available physical
On 12/10/21 12:55 AM, Zhen Lei wrote:
From: Chen Zhou
When reserving crashkernel in high memory, some low memory is reserved
for crash dump kernel devices and never mapped by the first kernel.
This memory range is advertised to crash dump kernel via DT property
under /chosen,
linux,usa
On 12/10/21 12:55 AM, Zhen Lei wrote:
From: Chen Zhou
Introduce macro CRASH_ALIGN for alignment, macro CRASH_ADDR_LOW_MAX
for upper bound of low crash memory, macro CRASH_ADDR_HIGH_MAX for
upper bound of high crash memory, use macros instead.
Besides, keep consistent with x86, use CRASH_ALIGN
On 12/10/21 12:55 AM, Zhen Lei wrote:
From: Chen Zhou
There are following issues in arm64 kdump:
1. We use crashkernel=X to reserve crashkernel below 4G, which
will fail when there is no enough low memory.
2. If reserving crashkernel above 4G, in this case, crash dump
kernel will boot failure b
On 12/10/21 12:55 AM, Zhen Lei wrote:
From: Chen Zhou
We will make the functions reserve_crashkernel() as generic, the
xen_pv_domain() check in reserve_crashkernel() is relevant only to
x86, the same as insert_resource() in reserve_crashkernel[_low]().
So move xen_pv_domain() check and insert_r
On 12/10/21 12:55 AM, Zhen Lei wrote:
From: Chen Zhou
Make the functions reserve_crashkernel[_low]() as generic. Since
reserve_crashkernel[_low]() implementations are quite similar on other
architectures as well, we can have more users of this later.
So have CONFIG_ARCH_WANT_RESERVE_CRASH_KERN
On 12/10/21 12:55 AM, Zhen Lei wrote:
From: Chen Zhou
The lower bounds of crash kernel reservation and crash kernel low
reservation are different, use the consistent value CRASH_ALIGN.
Suggested-by: Dave Young
Signed-off-by: Chen Zhou
Signed-off-by: Zhen Lei
Tested-by: John Donnelly
Tested
On 12/10/21 12:55 AM, Zhen Lei wrote:
From: Chen Zhou
To make the functions reserve_crashkernel() as generic,
replace some hard-coded numbers with macro CRASH_ADDR_LOW_MAX.
Signed-off-by: Chen Zhou
Signed-off-by: Zhen Lei
Tested-by: John Donnelly
Tested-by: Dave Kleikamp
Acked-by: Baoquan
On 12/10/21 12:55 AM, Zhen Lei wrote:
From: Chen Zhou
Move CRASH_ALIGN to header asm/kexec.h for later use.
Suggested-by: Dave Young
Suggested-by: Baoquan He
Signed-off-by: Chen Zhou
Signed-off-by: Zhen Lei
Tested-by: John Donnelly
Tested-by: Dave Kleikamp
>
Acked-by: John Donnelly
On 12/13/21 6:27 AM, Baoquan He wrote:
Dma-kmalloc will be created as long as CONFIG_ZONE_DMA is enabled.
However, it will fail if DMA zone has no managed pages. The failure
can be seen in kdump kernel of x86_64 as below:
CPU: 0 PID: 65 Comm: kworker/u2:1 Not tainted 5.14.0-rc2+ #9
Hardware
On 12/13/21 6:27 AM, Baoquan He wrote:
Currently three dma atomic pools are initialized as long as the relevant
kernel codes are built in. While in kdump kernel of x86_64, this is not
right when trying to create atomic_pool_dma, because there's no managed
pages in DMA zone. In the case, DMA zone
On 12/13/21 6:27 AM, Baoquan He wrote:
In some places of the current kernel, it assumes that dma zone must have
managed pages if CONFIG_ZONE_DMA is enabled. While this is not always true.
E.g in kdump kernel of x86_64, only low 1M is presented and locked down
at very early stage of boot, so that
On 12/13/21 6:27 AM, Baoquan He wrote:
Since commit 1d659236fb43("dma-pool: scale the default DMA coherent pool
size with memory capacity"), the default size of atomic pool has been
changed to take by scaling with system memory capacity. So update the
document in kerenl-parameter.txt accordingly.
On 12/13/21 6:27 AM, Baoquan He wrote:
In the current code, three atomic memory pools are always created,
atomic_pool_kernel|dma|dma32, even though 'coherent_pool=0' is
specified in kernel command line. In fact, atomic pool is only
necessary when CONFIG_DMA_DIRECT_REMAP=y or mem_encrypt_active=y
On 12/8/21 11:13 AM, Catalin Marinas wrote:
On Tue, Nov 23, 2021 at 08:46:35PM +0800, Zhen Lei wrote:
Chen Zhou (10):
x86: kdump: replace the hard-coded alignment with macro CRASH_ALIGN
x86: kdump: make the lower bound of crash kernel reservation
consistent
x86: kdump: use macro CR
On 11/23/21 6:46 AM, Zhen Lei wrote:
There are following issues in arm64 kdump:
1. We use crashkernel=X to reserve crashkernel below 4G, which
will fail when there is no enough low memory.
2. If reserving crashkernel above 4G, in this case, crash dump
kernel will boot failure because there is no
On 2/25/21 6:38 PM, Dave Young wrote:
On 02/23/21 at 09:41am, Saeed Mirzamohammadi wrote:
This adds crashkernel=auto feature to configure reserved memory for
vmcore creation. CONFIG_CRASH_AUTO_STR is defined to be set for
different kernel distributions and different archs based on their
needs.
On 2/17/21 8:02 PM, Baoquan He wrote:
On 02/11/21 at 10:08am, Saeed Mirzamohammadi wrote:
This adds crashkernel=auto feature to configure reserved memory for
vmcore creation. CONFIG_CRASH_AUTO_STR is defined to be set for
different kernel distributions and different archs based on their
needs.
On 2/11/21 12:08 PM, Saeed Mirzamohammadi wrote:
This adds crashkernel=auto feature to configure reserved memory for
vmcore creation. CONFIG_CRASH_AUTO_STR is defined to be set for
different kernel distributions and different archs based on their
needs.
Signed-off-by: Saeed Mirzamohammadi
Signe
On 11/22/20 9:47 PM, Dave Young wrote:
Hi Guilherme,
On 11/22/20 at 12:32pm, Guilherme Piccoli wrote:
Hi Dave and Kairui, thanks for your responses! OK, if that makes sense
to you I'm fine with it. I'd just recommend to test recent kernels in
multiple distros with the minimum "range" to see if 6
40 matches
Mail list logo
