Hello Michael,
On 22/11/23 18:22, Michael Ellerman wrote:
Sourabh Jain writes:
On 22/11/23 10:47, Michael Ellerman wrote:
Aneesh Kumar K V writes:
...
I am not sure whether we need to add all the complexity to enable supporting
different fadump kernel
version. Is that even a possible use c
Hello Aneesh,
On 22/11/23 17:50, Aneesh Kumar K V wrote:
On 11/22/23 4:05 PM, Sourabh Jain wrote:
Hello Michael,
On 22/11/23 10:47, Michael Ellerman wrote:
Aneesh Kumar K V writes:
...
I am not sure whether we need to add all the complexity to enable supporting
different fadump kernel
ver
Sourabh Jain writes:
> On 22/11/23 10:47, Michael Ellerman wrote:
>> Aneesh Kumar K V writes:
>> ...
>>> I am not sure whether we need to add all the complexity to enable
>>> supporting different fadump kernel
>>> version. Is that even a possible use case with fadump? Can't we always
>>> assume
On 11/22/23 4:05 PM, Sourabh Jain wrote:
> Hello Michael,
>
>
> On 22/11/23 10:47, Michael Ellerman wrote:
>> Aneesh Kumar K V writes:
>> ...
>>> I am not sure whether we need to add all the complexity to enable
>>> supporting different fadump kernel
>>> version. Is that even a possible use cas
Hello Michael,
On 22/11/23 10:47, Michael Ellerman wrote:
Aneesh Kumar K V writes:
...
I am not sure whether we need to add all the complexity to enable supporting
different fadump kernel
version. Is that even a possible use case with fadump? Can't we always assume
that with fadump the
cras
Aneesh Kumar K V writes:
...
>
> I am not sure whether we need to add all the complexity to enable supporting
> different fadump kernel
> version. Is that even a possible use case with fadump? Can't we always assume
> that with fadump the
> crash kernel and fadump kernel will be same version?
H
On 17/11/23 11:01 am, Aneesh Kumar K V wrote:
On 11/17/23 10:03 AM, Sourabh Jain wrote:
Hi Aneesh,
Thanks for reviewing the patch.
On 15/11/23 10:14, Aneesh Kumar K.V wrote:
Sourabh JainĀ writes:
diff --git a/arch/powerpc/include/asm/fadump-internal.h
b/arch/powerpc/include/asm/fa
On 11/17/23 10:03 AM, Sourabh Jain wrote:
> Hi Aneesh,
>
> Thanks for reviewing the patch.
>
> On 15/11/23 10:14, Aneesh Kumar K.V wrote:
>> Sourabh JainĀ writes:
>>
>>
>>
>>> diff --git a/arch/powerpc/include/asm/fadump-internal.h
>>> b/arch/powerpc/include/asm/fadump-internal.h
>>> index
Hi Aneesh,
Thanks for reviewing the patch.
On 15/11/23 10:14, Aneesh Kumar K.V wrote:
Sourabh Jain writes:
diff --git a/arch/powerpc/include/asm/fadump-internal.h
b/arch/powerpc/include/asm/fadump-internal.h
index 27f9e11eda28..7be3d8894520 100644
--- a/arch/powerpc/include/asm/fadump
Sourabh Jain writes:
> diff --git a/arch/powerpc/include/asm/fadump-internal.h
> b/arch/powerpc/include/asm/fadump-internal.h
> index 27f9e11eda28..7be3d8894520 100644
> --- a/arch/powerpc/include/asm/fadump-internal.h
> +++ b/arch/powerpc/include/asm/fadump-internal.h
> @@ -42,7 +42,25 @@
Hello Michael,
On 09/11/23 17:44, Michael Ellerman wrote:
Hi Sourabh,
This seems like a good change to the design, but I'm confused by
some things, more below ...
Thanks.
Sourabh Jain writes:
...
Table 1 below illustrates kernel's ability to collect dump if either the
first/crashed kerne
Hi Sourabh,
This seems like a good change to the design, but I'm confused by
some things, more below ...
Sourabh Jain writes:
>
...
>
> Table 1 below illustrates kernel's ability to collect dump if either the
> first/crashed kernel or the second/fadump kernel does not have the
> changes introduc
Due to changes in memory resources caused by either memory hotplug or
online/offline events, the elfcorehdr, which describes the CPUs and
memory of the crashed kernel to the kernel that collects the dump (known
as second/fadump kernel), becomes outdated. Consequently, attempting
dump collection wit
13 matches
Mail list logo