* kdump: Getting "warn_alloc" warning during boot of kdump kernel
@ 2020-05-15 10:58 ` Prabhakar Kushwaha
0 siblings, 0 replies; 6+ messages in thread
From: Prabhakar Kushwaha @ 2020-05-15 10:58 UTC (permalink / raw)
To: linux-arm-kernel, kexec mailing list
Cc: Catalin Marinas, Kamlakant Patel, Prabhakar Kushwaha,
Will Deacon, Ganapatrao Prabhakerrao Kulkarni
Hi All,
We are getting "warn_alloc" warning during boot of kdump kernel. This
warning is observed with latest upstream tag (v5.7-rc5).
Primary/1st Kernel
----------------------------
# dmesg | grep crash
[ 0.000000] crashkernel reserved: 0x00000000d6000000 -
0x00000000f6000000 (512 MB)
[ 0.000000] Kernel command line:
BOOT_IMAGE=(hd8,gpt2)/vmlinuz-5.7.0-rc5
root=UUID=c4050f17-526f-48a8-9804-c6b35cbb584c ro crashkernel=512M
earlycon console=ttyAMA0
# cat /proc/iomem | grep -i crash
d6000000 - f6000000 : Crash kernel
Logs from Kdump/crash kernel with warnings & dump_stack
------------------------------------------------------------------------
[ 0.239360] swapper/0: page allocation failure: order:2,
mode:0x1(GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
[ 0.249917] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc5 #44
[ 0.256246] Hardware name: To be filled by O.E.M. Saber/Saber, BIOS
0ACKL027 07/01/2019
[ 0.264333] Call trace:
[ 0.266797] dump_backtrace+0x0/0x1f8
[ 0.270490] show_stack+0x20/0x30
[ 0.273833] dump_stack+0xc0/0x10c
[ 0.277263] warn_alloc+0x10c/0x178
[ 0.280781] __alloc_pages_slowpath.constprop.112+0xaec/0xb28
[ 0.286584] __alloc_pages_nodemask+0x2b4/0x300
[ 0.291156] alloc_page_interleave+0x24/0xa0
[ 0.295464] alloc_pages_current+0xe4/0x108
[ 0.299686] dma_atomic_pool_init+0x44/0x1a4
[ 0.303995] do_one_initcall+0x54/0x228
[ 0.307864] kernel_init_freeable+0x228/0x2cc
[ 0.312263] kernel_init+0x1c/0x110
[ 0.315781] ret_from_fork+0x10/0x18
We did some debugging.
As per commit 1a8e1cef7603 ("arm64: use both ZONE_DMA and ZONE_DMA32")
. DMA zone has been re-defined.
here, ZONE_DMA has a fixed range of 0x802f0000 - 0xbfffffff and
ZONE_DMA32 has range from 0xc0000000-0xfffffffff.
When bootargs is defined with "crashkernel= X" for 1st/primary kernel.
Than X amount of memory is reserved in First kernel. This reserved
memory is used to boot kdump/crash kernel and represented as "Crash
kernel" in cat /prom/iomem.
If some region of reserved memory(Crash kernel) **does not** fall in
ZONE_DMA region i.e. 0x802f0000 - 0xbfffffff, this warning is
observed.
Other drivers like scsi_register_driver [1] also fail. We also see
other kinds of error [2].
Considering DMA_ZONE has requirement of 0x802f0000 - 0xbfffffff.
Can we enforce "Crash kernel" to always reserved between 0x0000_0000
to 0xc000_0000 in reserve_crashkernel() -->memblock_find_in_range()
or
what could be best possible solution.
--pk
[1]
------------------------------------------------------------
[ 21.509239] dump_backtrace+0x0/0x1f8
[ 21.516592] show_stack+0x20/0x30
[ 21.523248] dump_stack+0xc0/0x10c
[ 21.530087] warn_alloc+0x10c/0x178
[ 21.537090] __alloc_pages_slowpath.constprop.112+0xaec/0xb28
[ 21.548644] __alloc_pages_nodemask+0x2b4/0x300
[ 21.557750] alloc_pages_current+0x90/0x108
[ 21.566155] alloc_slab_page+0x184/0x340
[ 21.574030] new_slab+0x420/0x4c8
[ 21.580681] ___slab_alloc+0x354/0x4e8
[ 21.588207] __slab_alloc+0x28/0x58
[ 21.595210] kmem_cache_alloc_trace+0x230/0x250
[ 21.604316] sr_probe+0x250/0x618 [sr_mod]
[ 21.612555] really_probe+0xe4/0x448
[ 21.619733] driver_probe_device+0xe8/0x140
[ 21.628136] device_driver_attach+0x7c/0x88
[ 21.636536] __driver_attach+0xac/0x178
[ 21.644239] bus_for_each_dev+0x7c/0xd0
[ 21.651943] driver_attach+0x2c/0x38
[ 21.659119] bus_add_driver+0x1a8/0x240
[ 21.666823] driver_register+0x6c/0x128
[ 21.674533] scsi_register_driver+0x28/0x38
[ 21.682939] init_sr+0x40/0x10000 [sr_mod]
[2]
-------------------------------------------------------------------
[ 21.450571] systemd-udevd: page allocation failure: order:0,
mode:0xcc1(GFP_KERNEL|GFP_DMA),
nodemask=(null),cpuset=/,mems_allowed=0^M
[ 21.450571] systemd-udevd: page allocation failure: order:0,
mode:0xcc1(GFP_KERNEL|GFP_DMA),
nodemask=(null),cpuset=/,mems_allowed=0^M
_______________________________________________
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
* kdump: Getting "warn_alloc" warning during boot of kdump kernel
@ 2020-05-15 10:58 ` Prabhakar Kushwaha
0 siblings, 0 replies; 6+ messages in thread
From: Prabhakar Kushwaha @ 2020-05-15 10:58 UTC (permalink / raw)
To: linux-arm-kernel, kexec mailing list
Cc: Catalin Marinas, Kamlakant Patel, Prabhakar Kushwaha,
Will Deacon, Ganapatrao Prabhakerrao Kulkarni
Hi All,
We are getting "warn_alloc" warning during boot of kdump kernel. This
warning is observed with latest upstream tag (v5.7-rc5).
Primary/1st Kernel
----------------------------
# dmesg | grep crash
[ 0.000000] crashkernel reserved: 0x00000000d6000000 -
0x00000000f6000000 (512 MB)
[ 0.000000] Kernel command line:
BOOT_IMAGE=(hd8,gpt2)/vmlinuz-5.7.0-rc5
root=UUID=c4050f17-526f-48a8-9804-c6b35cbb584c ro crashkernel=512M
earlycon console=ttyAMA0
# cat /proc/iomem | grep -i crash
d6000000 - f6000000 : Crash kernel
Logs from Kdump/crash kernel with warnings & dump_stack
------------------------------------------------------------------------
[ 0.239360] swapper/0: page allocation failure: order:2,
mode:0x1(GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
[ 0.249917] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc5 #44
[ 0.256246] Hardware name: To be filled by O.E.M. Saber/Saber, BIOS
0ACKL027 07/01/2019
[ 0.264333] Call trace:
[ 0.266797] dump_backtrace+0x0/0x1f8
[ 0.270490] show_stack+0x20/0x30
[ 0.273833] dump_stack+0xc0/0x10c
[ 0.277263] warn_alloc+0x10c/0x178
[ 0.280781] __alloc_pages_slowpath.constprop.112+0xaec/0xb28
[ 0.286584] __alloc_pages_nodemask+0x2b4/0x300
[ 0.291156] alloc_page_interleave+0x24/0xa0
[ 0.295464] alloc_pages_current+0xe4/0x108
[ 0.299686] dma_atomic_pool_init+0x44/0x1a4
[ 0.303995] do_one_initcall+0x54/0x228
[ 0.307864] kernel_init_freeable+0x228/0x2cc
[ 0.312263] kernel_init+0x1c/0x110
[ 0.315781] ret_from_fork+0x10/0x18
We did some debugging.
As per commit 1a8e1cef7603 ("arm64: use both ZONE_DMA and ZONE_DMA32")
. DMA zone has been re-defined.
here, ZONE_DMA has a fixed range of 0x802f0000 - 0xbfffffff and
ZONE_DMA32 has range from 0xc0000000-0xfffffffff.
When bootargs is defined with "crashkernel= X" for 1st/primary kernel.
Than X amount of memory is reserved in First kernel. This reserved
memory is used to boot kdump/crash kernel and represented as "Crash
kernel" in cat /prom/iomem.
If some region of reserved memory(Crash kernel) **does not** fall in
ZONE_DMA region i.e. 0x802f0000 - 0xbfffffff, this warning is
observed.
Other drivers like scsi_register_driver [1] also fail. We also see
other kinds of error [2].
Considering DMA_ZONE has requirement of 0x802f0000 - 0xbfffffff.
Can we enforce "Crash kernel" to always reserved between 0x0000_0000
to 0xc000_0000 in reserve_crashkernel() -->memblock_find_in_range()
or
what could be best possible solution.
--pk
[1]
------------------------------------------------------------
[ 21.509239] dump_backtrace+0x0/0x1f8
[ 21.516592] show_stack+0x20/0x30
[ 21.523248] dump_stack+0xc0/0x10c
[ 21.530087] warn_alloc+0x10c/0x178
[ 21.537090] __alloc_pages_slowpath.constprop.112+0xaec/0xb28
[ 21.548644] __alloc_pages_nodemask+0x2b4/0x300
[ 21.557750] alloc_pages_current+0x90/0x108
[ 21.566155] alloc_slab_page+0x184/0x340
[ 21.574030] new_slab+0x420/0x4c8
[ 21.580681] ___slab_alloc+0x354/0x4e8
[ 21.588207] __slab_alloc+0x28/0x58
[ 21.595210] kmem_cache_alloc_trace+0x230/0x250
[ 21.604316] sr_probe+0x250/0x618 [sr_mod]
[ 21.612555] really_probe+0xe4/0x448
[ 21.619733] driver_probe_device+0xe8/0x140
[ 21.628136] device_driver_attach+0x7c/0x88
[ 21.636536] __driver_attach+0xac/0x178
[ 21.644239] bus_for_each_dev+0x7c/0xd0
[ 21.651943] driver_attach+0x2c/0x38
[ 21.659119] bus_add_driver+0x1a8/0x240
[ 21.666823] driver_register+0x6c/0x128
[ 21.674533] scsi_register_driver+0x28/0x38
[ 21.682939] init_sr+0x40/0x10000 [sr_mod]
[2]
-------------------------------------------------------------------
[ 21.450571] systemd-udevd: page allocation failure: order:0,
mode:0xcc1(GFP_KERNEL|GFP_DMA),
nodemask=(null),cpuset=/,mems_allowed=0^M
[ 21.450571] systemd-udevd: page allocation failure: order:0,
mode:0xcc1(GFP_KERNEL|GFP_DMA),
nodemask=(null),cpuset=/,mems_allowed=0^M
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: kdump: Getting "warn_alloc" warning during boot of kdump kernel
2020-05-15 10:58 ` Prabhakar Kushwaha
@ 2020-05-27 3:14 ` Prabhakar Kushwaha
-1 siblings, 0 replies; 6+ messages in thread
From: Prabhakar Kushwaha @ 2020-05-27 3:14 UTC (permalink / raw)
To: linux-arm-kernel, kexec mailing list
Cc: John Donnelly, Ganapatrao Prabhakerrao Kulkarni, Catalin Marinas,
Bhupesh Sharma, Kamlakant Patel, Prabhakar Kushwaha, Will Deacon
Hi All,
On Fri, May 15, 2020 at 4:28 PM Prabhakar Kushwaha
<prabhakar.pkin@gmail.com> wrote:
>
> Hi All,
>
> We are getting "warn_alloc" warning during boot of kdump kernel. This
> warning is observed with latest upstream tag (v5.7-rc5).
>
> Primary/1st Kernel
> ----------------------------
> # dmesg | grep crash
> [ 0.000000] crashkernel reserved: 0x00000000d6000000 -
> 0x00000000f6000000 (512 MB)
> [ 0.000000] Kernel command line:
> BOOT_IMAGE=(hd8,gpt2)/vmlinuz-5.7.0-rc5
> root=UUID=c4050f17-526f-48a8-9804-c6b35cbb584c ro crashkernel=512M
> earlycon console=ttyAMA0
>
> # cat /proc/iomem | grep -i crash
> d6000000 - f6000000 : Crash kernel
>
> Logs from Kdump/crash kernel with warnings & dump_stack
> ------------------------------------------------------------------------
>
> [ 0.239360] swapper/0: page allocation failure: order:2,
> mode:0x1(GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
> [ 0.249917] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc5 #44
> [ 0.256246] Hardware name: To be filled by O.E.M. Saber/Saber, BIOS
> 0ACKL027 07/01/2019
> [ 0.264333] Call trace:
> [ 0.266797] dump_backtrace+0x0/0x1f8
> [ 0.270490] show_stack+0x20/0x30
> [ 0.273833] dump_stack+0xc0/0x10c
> [ 0.277263] warn_alloc+0x10c/0x178
> [ 0.280781] __alloc_pages_slowpath.constprop.112+0xaec/0xb28
> [ 0.286584] __alloc_pages_nodemask+0x2b4/0x300
> [ 0.291156] alloc_page_interleave+0x24/0xa0
> [ 0.295464] alloc_pages_current+0xe4/0x108
> [ 0.299686] dma_atomic_pool_init+0x44/0x1a4
> [ 0.303995] do_one_initcall+0x54/0x228
> [ 0.307864] kernel_init_freeable+0x228/0x2cc
> [ 0.312263] kernel_init+0x1c/0x110
> [ 0.315781] ret_from_fork+0x10/0x18
>
> We did some debugging.
> As per commit 1a8e1cef7603 ("arm64: use both ZONE_DMA and ZONE_DMA32")
> . DMA zone has been re-defined.
> here, ZONE_DMA has a fixed range of 0x802f0000 - 0xbfffffff and
> ZONE_DMA32 has range from 0xc0000000-0xfffffffff.
>
> When bootargs is defined with "crashkernel= X" for 1st/primary kernel.
> Than X amount of memory is reserved in First kernel. This reserved
> memory is used to boot kdump/crash kernel and represented as "Crash
> kernel" in cat /prom/iomem.
>
> If some region of reserved memory(Crash kernel) **does not** fall in
> ZONE_DMA region i.e. 0x802f0000 - 0xbfffffff, this warning is
> observed.
> Other drivers like scsi_register_driver [1] also fail. We also see
> other kinds of error [2].
>
> Considering DMA_ZONE has requirement of 0x802f0000 - 0xbfffffff.
> Can we enforce "Crash kernel" to always reserved between 0x0000_0000
> to 0xc000_0000 in reserve_crashkernel() -->memblock_find_in_range()
> or
> what could be best possible solution.
>
I saw similar error https://lkml.org/lkml/2020/2/24/746 with no
solution mentioned or Luckily next time reserve fell in address range
of DMA_ZONE,
This error was mentioned in context of patch series "support
reserving crashkernel above 4G on arm64 kdump. Link
https://lkml.org/lkml/2019/12/23/411"
But this error is observable without the mentioned patch series.
As mentioned in previous mail, can we consider enforcing "Crash
kernel" to be always reserved between 0x0000_0000 - 0xc000_0000.
or any other best possible solution.
Please suggest..
--pk
>
> [1]
> ------------------------------------------------------------
> [ 21.509239] dump_backtrace+0x0/0x1f8
> [ 21.516592] show_stack+0x20/0x30
> [ 21.523248] dump_stack+0xc0/0x10c
> [ 21.530087] warn_alloc+0x10c/0x178
> [ 21.537090] __alloc_pages_slowpath.constprop.112+0xaec/0xb28
> [ 21.548644] __alloc_pages_nodemask+0x2b4/0x300
> [ 21.557750] alloc_pages_current+0x90/0x108
> [ 21.566155] alloc_slab_page+0x184/0x340
> [ 21.574030] new_slab+0x420/0x4c8
> [ 21.580681] ___slab_alloc+0x354/0x4e8
> [ 21.588207] __slab_alloc+0x28/0x58
> [ 21.595210] kmem_cache_alloc_trace+0x230/0x250
> [ 21.604316] sr_probe+0x250/0x618 [sr_mod]
> [ 21.612555] really_probe+0xe4/0x448
> [ 21.619733] driver_probe_device+0xe8/0x140
> [ 21.628136] device_driver_attach+0x7c/0x88
> [ 21.636536] __driver_attach+0xac/0x178
> [ 21.644239] bus_for_each_dev+0x7c/0xd0
> [ 21.651943] driver_attach+0x2c/0x38
> [ 21.659119] bus_add_driver+0x1a8/0x240
> [ 21.666823] driver_register+0x6c/0x128
> [ 21.674533] scsi_register_driver+0x28/0x38
> [ 21.682939] init_sr+0x40/0x10000 [sr_mod]
>
> [2]
> -------------------------------------------------------------------
> [ 21.450571] systemd-udevd: page allocation failure: order:0,
> mode:0xcc1(GFP_KERNEL|GFP_DMA),
> nodemask=(null),cpuset=/,mems_allowed=0^M
> [ 21.450571] systemd-udevd: page allocation failure: order:0,
> mode:0xcc1(GFP_KERNEL|GFP_DMA),
> nodemask=(null),cpuset=/,mems_allowed=0^M
_______________________________________________
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: kdump: Getting "warn_alloc" warning during boot of kdump kernel
@ 2020-05-27 3:14 ` Prabhakar Kushwaha
0 siblings, 0 replies; 6+ messages in thread
From: Prabhakar Kushwaha @ 2020-05-27 3:14 UTC (permalink / raw)
To: linux-arm-kernel, kexec mailing list
Cc: John Donnelly, Ganapatrao Prabhakerrao Kulkarni, Catalin Marinas,
Bhupesh Sharma, Kamlakant Patel, Prabhakar Kushwaha, Will Deacon
Hi All,
On Fri, May 15, 2020 at 4:28 PM Prabhakar Kushwaha
<prabhakar.pkin@gmail.com> wrote:
>
> Hi All,
>
> We are getting "warn_alloc" warning during boot of kdump kernel. This
> warning is observed with latest upstream tag (v5.7-rc5).
>
> Primary/1st Kernel
> ----------------------------
> # dmesg | grep crash
> [ 0.000000] crashkernel reserved: 0x00000000d6000000 -
> 0x00000000f6000000 (512 MB)
> [ 0.000000] Kernel command line:
> BOOT_IMAGE=(hd8,gpt2)/vmlinuz-5.7.0-rc5
> root=UUID=c4050f17-526f-48a8-9804-c6b35cbb584c ro crashkernel=512M
> earlycon console=ttyAMA0
>
> # cat /proc/iomem | grep -i crash
> d6000000 - f6000000 : Crash kernel
>
> Logs from Kdump/crash kernel with warnings & dump_stack
> ------------------------------------------------------------------------
>
> [ 0.239360] swapper/0: page allocation failure: order:2,
> mode:0x1(GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
> [ 0.249917] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc5 #44
> [ 0.256246] Hardware name: To be filled by O.E.M. Saber/Saber, BIOS
> 0ACKL027 07/01/2019
> [ 0.264333] Call trace:
> [ 0.266797] dump_backtrace+0x0/0x1f8
> [ 0.270490] show_stack+0x20/0x30
> [ 0.273833] dump_stack+0xc0/0x10c
> [ 0.277263] warn_alloc+0x10c/0x178
> [ 0.280781] __alloc_pages_slowpath.constprop.112+0xaec/0xb28
> [ 0.286584] __alloc_pages_nodemask+0x2b4/0x300
> [ 0.291156] alloc_page_interleave+0x24/0xa0
> [ 0.295464] alloc_pages_current+0xe4/0x108
> [ 0.299686] dma_atomic_pool_init+0x44/0x1a4
> [ 0.303995] do_one_initcall+0x54/0x228
> [ 0.307864] kernel_init_freeable+0x228/0x2cc
> [ 0.312263] kernel_init+0x1c/0x110
> [ 0.315781] ret_from_fork+0x10/0x18
>
> We did some debugging.
> As per commit 1a8e1cef7603 ("arm64: use both ZONE_DMA and ZONE_DMA32")
> . DMA zone has been re-defined.
> here, ZONE_DMA has a fixed range of 0x802f0000 - 0xbfffffff and
> ZONE_DMA32 has range from 0xc0000000-0xfffffffff.
>
> When bootargs is defined with "crashkernel= X" for 1st/primary kernel.
> Than X amount of memory is reserved in First kernel. This reserved
> memory is used to boot kdump/crash kernel and represented as "Crash
> kernel" in cat /prom/iomem.
>
> If some region of reserved memory(Crash kernel) **does not** fall in
> ZONE_DMA region i.e. 0x802f0000 - 0xbfffffff, this warning is
> observed.
> Other drivers like scsi_register_driver [1] also fail. We also see
> other kinds of error [2].
>
> Considering DMA_ZONE has requirement of 0x802f0000 - 0xbfffffff.
> Can we enforce "Crash kernel" to always reserved between 0x0000_0000
> to 0xc000_0000 in reserve_crashkernel() -->memblock_find_in_range()
> or
> what could be best possible solution.
>
I saw similar error https://lkml.org/lkml/2020/2/24/746 with no
solution mentioned or Luckily next time reserve fell in address range
of DMA_ZONE,
This error was mentioned in context of patch series "support
reserving crashkernel above 4G on arm64 kdump. Link
https://lkml.org/lkml/2019/12/23/411"
But this error is observable without the mentioned patch series.
As mentioned in previous mail, can we consider enforcing "Crash
kernel" to be always reserved between 0x0000_0000 - 0xc000_0000.
or any other best possible solution.
Please suggest..
--pk
>
> [1]
> ------------------------------------------------------------
> [ 21.509239] dump_backtrace+0x0/0x1f8
> [ 21.516592] show_stack+0x20/0x30
> [ 21.523248] dump_stack+0xc0/0x10c
> [ 21.530087] warn_alloc+0x10c/0x178
> [ 21.537090] __alloc_pages_slowpath.constprop.112+0xaec/0xb28
> [ 21.548644] __alloc_pages_nodemask+0x2b4/0x300
> [ 21.557750] alloc_pages_current+0x90/0x108
> [ 21.566155] alloc_slab_page+0x184/0x340
> [ 21.574030] new_slab+0x420/0x4c8
> [ 21.580681] ___slab_alloc+0x354/0x4e8
> [ 21.588207] __slab_alloc+0x28/0x58
> [ 21.595210] kmem_cache_alloc_trace+0x230/0x250
> [ 21.604316] sr_probe+0x250/0x618 [sr_mod]
> [ 21.612555] really_probe+0xe4/0x448
> [ 21.619733] driver_probe_device+0xe8/0x140
> [ 21.628136] device_driver_attach+0x7c/0x88
> [ 21.636536] __driver_attach+0xac/0x178
> [ 21.644239] bus_for_each_dev+0x7c/0xd0
> [ 21.651943] driver_attach+0x2c/0x38
> [ 21.659119] bus_add_driver+0x1a8/0x240
> [ 21.666823] driver_register+0x6c/0x128
> [ 21.674533] scsi_register_driver+0x28/0x38
> [ 21.682939] init_sr+0x40/0x10000 [sr_mod]
>
> [2]
> -------------------------------------------------------------------
> [ 21.450571] systemd-udevd: page allocation failure: order:0,
> mode:0xcc1(GFP_KERNEL|GFP_DMA),
> nodemask=(null),cpuset=/,mems_allowed=0^M
> [ 21.450571] systemd-udevd: page allocation failure: order:0,
> mode:0xcc1(GFP_KERNEL|GFP_DMA),
> nodemask=(null),cpuset=/,mems_allowed=0^M
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: kdump: Getting "warn_alloc" warning during boot of kdump kernel
2020-05-15 10:58 ` Prabhakar Kushwaha
@ 2020-06-01 7:34 ` Will Deacon
-1 siblings, 0 replies; 6+ messages in thread
From: Will Deacon @ 2020-06-01 7:34 UTC (permalink / raw)
To: Prabhakar Kushwaha
Cc: Ganapatrao Prabhakerrao Kulkarni, Catalin Marinas,
kexec mailing list, Kamlakant Patel, Prabhakar Kushwaha,
linux-arm-kernel
On Fri, May 15, 2020 at 04:28:13PM +0530, Prabhakar Kushwaha wrote:
> We are getting "warn_alloc" warning during boot of kdump kernel. This
> warning is observed with latest upstream tag (v5.7-rc5).
Perhaps you can help to review:
https://lore.kernel.org/r/20200521093805.64398-1-chenzhou10@huawei.com
Since it looks like it should solve your problem.
Will
_______________________________________________
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: kdump: Getting "warn_alloc" warning during boot of kdump kernel
@ 2020-06-01 7:34 ` Will Deacon
0 siblings, 0 replies; 6+ messages in thread
From: Will Deacon @ 2020-06-01 7:34 UTC (permalink / raw)
To: Prabhakar Kushwaha
Cc: Ganapatrao Prabhakerrao Kulkarni, Catalin Marinas,
kexec mailing list, Kamlakant Patel, Prabhakar Kushwaha,
linux-arm-kernel
On Fri, May 15, 2020 at 04:28:13PM +0530, Prabhakar Kushwaha wrote:
> We are getting "warn_alloc" warning during boot of kdump kernel. This
> warning is observed with latest upstream tag (v5.7-rc5).
Perhaps you can help to review:
https://lore.kernel.org/r/20200521093805.64398-1-chenzhou10@huawei.com
Since it looks like it should solve your problem.
Will
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-06-01 7:35 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-15 10:58 kdump: Getting "warn_alloc" warning during boot of kdump kernel Prabhakar Kushwaha
2020-05-15 10:58 ` Prabhakar Kushwaha
2020-05-27 3:14 ` Prabhakar Kushwaha
2020-05-27 3:14 ` Prabhakar Kushwaha
2020-06-01 7:34 ` Will Deacon
2020-06-01 7:34 ` Will Deacon
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.