* [BUG] arm64: kdump: capture kernel boot failed when crashkernel above 4G
@ 2019-03-23 10:34 Chen Zhou
2019-03-25 14:35 ` Catalin Marinas
0 siblings, 1 reply; 6+ messages in thread
From: Chen Zhou @ 2019-03-23 10:34 UTC (permalink / raw)
To: catalin.marinas, will.deacon, robin.murphy, steve.capper,
takahiro.akashi
Cc: wangyufen, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG] arm64: kdump: capture kernel boot failed when crashkernel above 4G
2019-03-23 10:34 [BUG] arm64: kdump: capture kernel boot failed when crashkernel above 4G Chen Zhou
@ 2019-03-25 14:35 ` Catalin Marinas
2019-03-26 8:25 ` Chen Zhou
2019-03-27 4:55 ` AKASHI Takahiro
0 siblings, 2 replies; 6+ messages in thread
From: Catalin Marinas @ 2019-03-25 14:35 UTC (permalink / raw)
To: Chen Zhou
Cc: wangyufen, steve.capper, will.deacon, takahiro.akashi,
robin.murphy, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG] arm64: kdump: capture kernel boot failed when crashkernel above 4G
2019-03-25 14:35 ` Catalin Marinas
@ 2019-03-26 8:25 ` Chen Zhou
2019-03-26 14:12 ` Catalin Marinas
2019-03-27 4:55 ` AKASHI Takahiro
1 sibling, 1 reply; 6+ messages in thread
From: Chen Zhou @ 2019-03-26 8:25 UTC (permalink / raw)
To: Catalin Marinas
Cc: wangyufen, steve.capper, will.deacon, takahiro.akashi,
robin.murphy, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG] arm64: kdump: capture kernel boot failed when crashkernel above 4G
2019-03-26 8:25 ` Chen Zhou
@ 2019-03-26 14:12 ` Catalin Marinas
0 siblings, 0 replies; 6+ messages in thread
From: Catalin Marinas @ 2019-03-26 14:12 UTC (permalink / raw)
To: Chen Zhou
Cc: wangyufen, steve.capper, will.deacon, takahiro.akashi,
robin.murphy, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG] arm64: kdump: capture kernel boot failed when crashkernel above 4G
2019-03-25 14:35 ` Catalin Marinas
2019-03-26 8:25 ` Chen Zhou
@ 2019-03-27 4:55 ` AKASHI Takahiro
2019-03-27 18:10 ` Catalin Marinas
1 sibling, 1 reply; 6+ messages in thread
From: AKASHI Takahiro @ 2019-03-27 4:55 UTC (permalink / raw)
To: Catalin Marinas
Cc: wangyufen, steve.capper, Chen Zhou, will.deacon, robin.murphy,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG] arm64: kdump: capture kernel boot failed when crashkernel above 4G
2019-03-27 4:55 ` AKASHI Takahiro
@ 2019-03-27 18:10 ` Catalin Marinas
0 siblings, 0 replies; 6+ messages in thread
From: Catalin Marinas @ 2019-03-27 18:10 UTC (permalink / raw)
To: AKASHI Takahiro, Chen Zhou, will.deacon, robin.murphy,
steve.capper, wangyufen, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-03-27 18:10 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-03-23 10:34 [BUG] arm64: kdump: capture kernel boot failed when crashkernel above 4G Chen Zhou
2019-03-25 14:35 ` Catalin Marinas
2019-03-26 8:25 ` Chen Zhou
2019-03-26 14:12 ` Catalin Marinas
2019-03-27 4:55 ` AKASHI Takahiro
2019-03-27 18:10 ` Catalin Marinas
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).