Hi Guilherme,
On 12/22/21 at 09:34am, Guilherme G. Piccoli wrote:
> On 22/12/2021 08:45, Dave Young wrote:
> > Hi Guilherme,
> >
> > Thanks for you patch. Could you add kexec list for any following up
> > patches? This could change kdump behavior so let's see if any comments
> > from kexec
On 2021/12/24 1:26, Borislav Petkov wrote:
> On Wed, Dec 22, 2021 at 09:08:05PM +0800, 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,
>
> Why is that so? Is
On 2021/12/23 23:48, Dave Kleikamp wrote:
> On 12/22/21 7:08AM, 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
>>
Estimado(a) ❤️ You have unread messages from Abby (2)! Click Here:
http://bit.do/fSXqL?4w1 ❤️,
Muchas gracias por llenar el formulario. Su mensaje ha sido recibido
correctamente. En breve estaremos en contacto con usted.
Saludos Cordiales.
Grupo Abundia SA
Tel. +51 (01) 637-1081 | +51
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/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
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
Hardware name: AMD Dinar/Dinar, BIOS RDN1505B
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 only has low 1M memory presented
and
**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 allocation failure: order:5,
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 there's no managed pages at all in
DMA
Looks good,
Reviewed-by: Christoph Hellwig
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Wed, Dec 22, 2021 at 12:37:03PM +, Hyeonggon Yoo wrote:
> Oh I misunderstood this. Underlying physical address of vmalloc()-allocated
> memory
> can be mapped using DMA API, and it needs to be setup as scatterlist because
> the allocated memory is not physically continuous. Right?
Yes.
>
On 12/22/21 7:08AM, 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 Wed, Dec 22, 2021 at 09:08:05PM +0800, 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,
Why is that so? Is Xen-PV x86-only?
> the same as insert_resource() in
15 matches
Mail list logo