[BUG] arm64: kdump: capture kernel boot failed when crashkernel above 4G

[BUG] arm64: kdump: capture kernel boot failed when crashkernel above 4G

[Chen Zhou]

Hi all,

When i tested kdump on arm64 with crashkernel=Y@X, the capture kernel boot failed if the start
address is above 4G.

My test steps:
1. set crashkernel=1024M@0x2040000000 and boot with ACPI
2. echo c > /proc/sysrq-trigger
3. boot capture kernel, failed

The failed log is as follows:
[2019/3/23 15:58:46] [    0.000000] Zone ranges:
[2019/3/23 15:58:46] [    0.000000]   DMA32    [mem 0x00000000395f0000-0x00000000ffffffff]
[2019/3/23 15:58:46] [    0.000000]   Normal   [mem 0x0000000100000000-0x000000207fffffff]
[2019/3/23 15:58:46] [    0.000000] Movable zone start for each node
[2019/3/23 15:58:46] [    0.000000] Early memory node ranges
[2019/3/23 15:58:46] [    0.000000]   node   0: [mem 0x00000000395f0000-0x000000003968ffff]
[2019/3/23 15:58:46] [    0.000000]   node   0: [mem 0x0000000039730000-0x000000003973ffff]
[2019/3/23 15:58:46] [    0.000000]   node   0: [mem 0x0000000039780000-0x000000003986ffff]
[2019/3/23 15:58:46] [    0.000000]   node   0: [mem 0x0000000039890000-0x0000000039d0ffff]
[2019/3/23 15:58:46] [    0.000000]   node   0: [mem 0x000000003ed00000-0x000000003ed2ffff]
[2019/3/23 15:58:46] [    0.000000]   node   0: [mem 0x0000002040000000-0x000000207fffffff]
[2019/3/23 15:58:46] [    0.000000] Initmem setup node 0 [mem 0x00000000395f0000-0x000000207fffffff]
[2019/3/23 15:58:47] [    0.000000] Could not find start_pfn for node 1
[2019/3/23 15:58:47] [    0.000000] Initmem setup node 1 [mem 0x0000000000000000-0x0000000000000000]
[2019/3/23 15:58:47] [    0.000000] Could not find start_pfn for node 2
[2019/3/23 15:58:47] [    0.000000] Initmem setup node 2 [mem 0x0000000000000000-0x0000000000000000]
[2019/3/23 15:58:47] [    0.000000] Could not find start_pfn for node 3
[2019/3/23 15:58:47] [    0.000000] Initmem setup node 3 [mem 0x0000000000000000-0x0000000000000000]
[2019/3/23 15:58:47] [    0.000000] MEMBLOCK configuration:
[2019/3/23 15:58:47] [    0.000000]  memory size = 0x0000000040650000 reserved size = 0x0000000004db7f39
[2019/3/23 15:58:47] [    0.000000]  memory.cnt  = 0x6
[2019/3/23 15:58:47] [    0.000000]  memory[0x0]	[0x00000000395f0000-0x000000003968ffff], 0x00000000000a0000 bytes on node 0 flags: 0x4
[2019/3/23 15:58:47] [    0.000000]  memory[0x1]	[0x0000000039730000-0x000000003973ffff], 0x0000000000010000 bytes on node 0 flags: 0x4
[2019/3/23 15:58:47] [    0.000000]  memory[0x2]	[0x0000000039780000-0x000000003986ffff], 0x00000000000f0000 bytes on node 0 flags: 0x4
[2019/3/23 15:58:47] [    0.000000]  memory[0x3]	[0x0000000039890000-0x0000000039d0ffff], 0x0000000000480000 bytes on node 0 flags: 0x4
[2019/3/23 15:58:47] [    0.000000]  memory[0x4]	[0x000000003ed00000-0x000000003ed2ffff], 0x0000000000030000 bytes on node 0 flags: 0x4
[2019/3/23 15:58:47] [    0.000000]  memory[0x5]	[0x0000002040000000-0x000000207fffffff], 0x0000000040000000 bytes on node 0 flags: 0x0
[2019/3/23 15:58:47] [    0.000000]  reserved.cnt  = 0x7
[2019/3/23 15:58:47] [    0.000000]  reserved[0x0]	[0x0000002040080000-0x0000002041c4dfff], 0x0000000001bce000 bytes flags: 0x0
[2019/3/23 15:58:47] [    0.000000]  reserved[0x1]	[0x0000002041c53000-0x0000002042c203f8], 0x0000000000fcd3f9 bytes flags: 0x0
[2019/3/23 15:58:47] [    0.000000]  reserved[0x2]	[0x000000207da00000-0x000000207dbfffff], 0x0000000000200000 bytes flags: 0x0
[2019/3/23 15:58:47] [    0.000000]  reserved[0x3]	[0x000000207ddef000-0x000000207fbfffff], 0x0000000001e11000 bytes flags: 0x0
[2019/3/23 15:58:47] [    0.000000]  reserved[0x4]	[0x000000207fdf2b00-0x000000207fdfc03f], 0x0000000000009540 bytes flags: 0x0
[2019/3/23 15:58:47] [    0.000000]  reserved[0x5]	[0x000000207fdfd000-0x000000207ffff3ff], 0x0000000000202400 bytes flags: 0x0
[2019/3/23 15:58:47] [    0.000000]  reserved[0x6]	[0x000000207ffffe00-0x000000207fffffff], 0x0000000000000200 bytes flags: 0x0
[2019/3/23 15:58:47] [    0.000000] Kernel panic - not syncing: request_standard_resources: Failed to allocate 384 bytes
[2019/3/23 15:58:47] [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.1.0-next-20190321+ #4
[2019/3/23 15:58:47] [    0.000000] Call trace:
[2019/3/23 15:58:47] [    0.000000]  dump_backtrace+0x0/0x188
[2019/3/23 15:58:47] [    0.000000]  show_stack+0x24/0x30
[2019/3/23 15:58:47] [    0.000000]  dump_stack+0xa8/0xcc
[2019/3/23 15:58:47] [    0.000000]  panic+0x14c/0x31c
[2019/3/23 15:58:47] [    0.000000]  setup_arch+0x2b0/0x5e0
[2019/3/23 15:58:47] [    0.000000]  start_kernel+0x90/0x52c
[2019/3/23 15:58:47] [    0.000000] ---[ end Kernel panic - not syncing: request_standard_resources: Failed to allocate 384 bytes ]---

The root cause is:
In capture kernel, memblock_alloc_low alloced memory in range [MEMBLOCK_LOW_LIMIT, ARCH_LOW_ADDRESS_LIMIT].
CONFIG_ZONE_DMA32 is enabled, and ARCH_LOW_ADDRESS_LIMIT equals to max_zone_dma_phys() - 1.
The return value of function max_zone_dma_phys is 4G due to the existing "no-map" memory below 4G.
So memblock_alloc_low alloced memory in range [0, 4G) and failed.

My temporary workaround:
1. use the first non "no map" memory as memblock_start_of_DRAM.

I have no good idea about this problem, could you give me some suggestions?

Thanks,
Chen Zhou




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [BUG] arm64: kdump: capture kernel boot failed when crashkernel above 4G

[Catalin Marinas]

Hi Chen,

On Sat, Mar 23, 2019 at 06:34:31PM +0800, Chen Zhou wrote:
> When i tested kdump on arm64 with crashkernel=Y@X, the capture kernel boot failed if the start
> address is above 4G.
> 
> My test steps:
> 1. set crashkernel=1024M@0x2040000000 and boot with ACPI
> 2. echo c > /proc/sysrq-trigger
> 3. boot capture kernel, failed
[...]
> [2019/3/23 15:58:47] [    0.000000] Call trace:
> [2019/3/23 15:58:47] [    0.000000]  dump_backtrace+0x0/0x188
> [2019/3/23 15:58:47] [    0.000000]  show_stack+0x24/0x30
> [2019/3/23 15:58:47] [    0.000000]  dump_stack+0xa8/0xcc
> [2019/3/23 15:58:47] [    0.000000]  panic+0x14c/0x31c
> [2019/3/23 15:58:47] [    0.000000]  setup_arch+0x2b0/0x5e0
> [2019/3/23 15:58:47] [    0.000000]  start_kernel+0x90/0x52c
> [2019/3/23 15:58:47] [    0.000000] ---[ end Kernel panic - not syncing: request_standard_resources: Failed to allocate 384 bytes ]---
> 
> The root cause is:
> In capture kernel, memblock_alloc_low alloced memory in range [MEMBLOCK_LOW_LIMIT, ARCH_LOW_ADDRESS_LIMIT].
> CONFIG_ZONE_DMA32 is enabled, and ARCH_LOW_ADDRESS_LIMIT equals to max_zone_dma_phys() - 1.
> The return value of function max_zone_dma_phys is 4G due to the existing "no-map" memory below 4G.
> So memblock_alloc_low alloced memory in range [0, 4G) and failed.

Does it work better if, in request_standard_resources(), we call
memblock_alloc() instead of the _low variant? I doubt we need the
*_low() call here.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [BUG] arm64: kdump: capture kernel boot failed when crashkernel above 4G

[Chen Zhou]

Hi Catalin,

On 2019/3/25 22:35, Catalin Marinas wrote:
> Hi Chen,
> 
> On Sat, Mar 23, 2019 at 06:34:31PM +0800, Chen Zhou wrote:
>> When i tested kdump on arm64 with crashkernel=Y@X, the capture kernel boot failed if the start
>> address is above 4G.
>>
>> My test steps:
>> 1. set crashkernel=1024M@0x2040000000 and boot with ACPI
>> 2. echo c > /proc/sysrq-trigger
>> 3. boot capture kernel, failed
> [...]
>> [2019/3/23 15:58:47] [    0.000000] Call trace:
>> [2019/3/23 15:58:47] [    0.000000]  dump_backtrace+0x0/0x188
>> [2019/3/23 15:58:47] [    0.000000]  show_stack+0x24/0x30
>> [2019/3/23 15:58:47] [    0.000000]  dump_stack+0xa8/0xcc
>> [2019/3/23 15:58:47] [    0.000000]  panic+0x14c/0x31c
>> [2019/3/23 15:58:47] [    0.000000]  setup_arch+0x2b0/0x5e0
>> [2019/3/23 15:58:47] [    0.000000]  start_kernel+0x90/0x52c
>> [2019/3/23 15:58:47] [    0.000000] ---[ end Kernel panic - not syncing: request_standard_resources: Failed to allocate 384 bytes ]---
>>
>> The root cause is:
>> In capture kernel, memblock_alloc_low alloced memory in range [MEMBLOCK_LOW_LIMIT, ARCH_LOW_ADDRESS_LIMIT].
>> CONFIG_ZONE_DMA32 is enabled, and ARCH_LOW_ADDRESS_LIMIT equals to max_zone_dma_phys() - 1.
>> The return value of function max_zone_dma_phys is 4G due to the existing "no-map" memory below 4G.
>> So memblock_alloc_low alloced memory in range [0, 4G) and failed.
> 
> Does it work better if, in request_standard_resources(), we call
> memblock_alloc() instead of the _low variant? I doubt we need the
> *_low() call here.
> 

Thanks for your reply. I used memblock_alloc() in request_standard_resources() and
request_standard_resources allocated successfully in capture kernel.

Thanks,
Chen Zhou


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [BUG] arm64: kdump: capture kernel boot failed when crashkernel above 4G

[Catalin Marinas]

On Tue, Mar 26, 2019 at 04:25:34PM +0800, Chen Zhou wrote:
> On 2019/3/25 22:35, Catalin Marinas wrote:
> > On Sat, Mar 23, 2019 at 06:34:31PM +0800, Chen Zhou wrote:
> >> When i tested kdump on arm64 with crashkernel=Y@X, the capture kernel boot failed if the start
> >> address is above 4G.
> >>
> >> My test steps:
> >> 1. set crashkernel=1024M@0x2040000000 and boot with ACPI
> >> 2. echo c > /proc/sysrq-trigger
> >> 3. boot capture kernel, failed
> > [...]
> >> [2019/3/23 15:58:47] [    0.000000] Call trace:
> >> [2019/3/23 15:58:47] [    0.000000]  dump_backtrace+0x0/0x188
> >> [2019/3/23 15:58:47] [    0.000000]  show_stack+0x24/0x30
> >> [2019/3/23 15:58:47] [    0.000000]  dump_stack+0xa8/0xcc
> >> [2019/3/23 15:58:47] [    0.000000]  panic+0x14c/0x31c
> >> [2019/3/23 15:58:47] [    0.000000]  setup_arch+0x2b0/0x5e0
> >> [2019/3/23 15:58:47] [    0.000000]  start_kernel+0x90/0x52c
> >> [2019/3/23 15:58:47] [    0.000000] ---[ end Kernel panic - not syncing: request_standard_resources: Failed to allocate 384 bytes ]---
> >>
> >> The root cause is:
> >> In capture kernel, memblock_alloc_low alloced memory in range [MEMBLOCK_LOW_LIMIT, ARCH_LOW_ADDRESS_LIMIT].
> >> CONFIG_ZONE_DMA32 is enabled, and ARCH_LOW_ADDRESS_LIMIT equals to max_zone_dma_phys() - 1.
> >> The return value of function max_zone_dma_phys is 4G due to the existing "no-map" memory below 4G.
> >> So memblock_alloc_low alloced memory in range [0, 4G) and failed.
> > 
> > Does it work better if, in request_standard_resources(), we call
> > memblock_alloc() instead of the _low variant? I doubt we need the
> > *_low() call here.
> 
> Thanks for your reply. I used memblock_alloc() in request_standard_resources() and
> request_standard_resources allocated successfully in capture kernel.

Would you mind sending a patch with your description above and the
memblock_alloc() change?

Thanks.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [BUG] arm64: kdump: capture kernel boot failed when crashkernel above 4G

[AKASHI Takahiro]

On Mon, Mar 25, 2019 at 02:35:05PM +0000, Catalin Marinas wrote:
> Hi Chen,
> 
> On Sat, Mar 23, 2019 at 06:34:31PM +0800, Chen Zhou wrote:
> > When i tested kdump on arm64 with crashkernel=Y@X, the capture kernel boot failed if the start
> > address is above 4G.
> > 
> > My test steps:
> > 1. set crashkernel=1024M@0x2040000000 and boot with ACPI
> > 2. echo c > /proc/sysrq-trigger
> > 3. boot capture kernel, failed
> [...]
> > [2019/3/23 15:58:47] [    0.000000] Call trace:
> > [2019/3/23 15:58:47] [    0.000000]  dump_backtrace+0x0/0x188
> > [2019/3/23 15:58:47] [    0.000000]  show_stack+0x24/0x30
> > [2019/3/23 15:58:47] [    0.000000]  dump_stack+0xa8/0xcc
> > [2019/3/23 15:58:47] [    0.000000]  panic+0x14c/0x31c
> > [2019/3/23 15:58:47] [    0.000000]  setup_arch+0x2b0/0x5e0
> > [2019/3/23 15:58:47] [    0.000000]  start_kernel+0x90/0x52c
> > [2019/3/23 15:58:47] [    0.000000] ---[ end Kernel panic - not syncing: request_standard_resources: Failed to allocate 384 bytes ]---
> > 
> > The root cause is:
> > In capture kernel, memblock_alloc_low alloced memory in range [MEMBLOCK_LOW_LIMIT, ARCH_LOW_ADDRESS_LIMIT].
> > CONFIG_ZONE_DMA32 is enabled, and ARCH_LOW_ADDRESS_LIMIT equals to max_zone_dma_phys() - 1.
> > The return value of function max_zone_dma_phys is 4G due to the existing "no-map" memory below 4G.
> > So memblock_alloc_low alloced memory in range [0, 4G) and failed.
> 
> Does it work better if, in request_standard_resources(), we call
> memblock_alloc() instead of the _low variant? I doubt we need the
> *_low() call here.

I've been aware of this issue in my testing, but I supposed
that there must be a reason for *_low() here to prevent the kernel
booting from higher address space.

-Takahiro Akashi

> -- 
> Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [BUG] arm64: kdump: capture kernel boot failed when crashkernel above 4G

[Catalin Marinas]

On Wed, Mar 27, 2019 at 01:55:16PM +0900, AKASHI Takahiro wrote:
> On Mon, Mar 25, 2019 at 02:35:05PM +0000, Catalin Marinas wrote:
> > On Sat, Mar 23, 2019 at 06:34:31PM +0800, Chen Zhou wrote:
> > > When i tested kdump on arm64 with crashkernel=Y@X, the capture kernel boot failed if the start
> > > address is above 4G.
> > > 
> > > My test steps:
> > > 1. set crashkernel=1024M@0x2040000000 and boot with ACPI
> > > 2. echo c > /proc/sysrq-trigger
> > > 3. boot capture kernel, failed
> > [...]
> > > [2019/3/23 15:58:47] [    0.000000] Call trace:
> > > [2019/3/23 15:58:47] [    0.000000]  dump_backtrace+0x0/0x188
> > > [2019/3/23 15:58:47] [    0.000000]  show_stack+0x24/0x30
> > > [2019/3/23 15:58:47] [    0.000000]  dump_stack+0xa8/0xcc
> > > [2019/3/23 15:58:47] [    0.000000]  panic+0x14c/0x31c
> > > [2019/3/23 15:58:47] [    0.000000]  setup_arch+0x2b0/0x5e0
> > > [2019/3/23 15:58:47] [    0.000000]  start_kernel+0x90/0x52c
> > > [2019/3/23 15:58:47] [    0.000000] ---[ end Kernel panic - not syncing: request_standard_resources: Failed to allocate 384 bytes ]---
> > > 
> > > The root cause is:
> > > In capture kernel, memblock_alloc_low alloced memory in range [MEMBLOCK_LOW_LIMIT, ARCH_LOW_ADDRESS_LIMIT].
> > > CONFIG_ZONE_DMA32 is enabled, and ARCH_LOW_ADDRESS_LIMIT equals to max_zone_dma_phys() - 1.
> > > The return value of function max_zone_dma_phys is 4G due to the existing "no-map" memory below 4G.
> > > So memblock_alloc_low alloced memory in range [0, 4G) and failed.
> > 
> > Does it work better if, in request_standard_resources(), we call
> > memblock_alloc() instead of the _low variant? I doubt we need the
> > *_low() call here.
> 
> I've been aware of this issue in my testing, but I supposed
> that there must be a reason for *_low() here to prevent the kernel
> booting from higher address space.

I don't remember why we had the *_low() variant, maybe we inherited it
from arm32 where only the low addresses are mapped.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel