On 14/08/19 3:48 PM, Mahesh J Salgaonkar wrote:
> On 2019-07-16 17:03:38 Tue, Hari Bathini wrote:
>> Add support in the kernel to process the crash'ed kernel's memory
>> preserved during MPIPL and export it as /proc/vmcore file for the
>> userland scripts to filter and analyze it later.
>>
>> Signed-off-by: Hari Bathini <hbath...@linux.ibm.com>
>> ---
>>  arch/powerpc/platforms/powernv/opal-fadump.c |  190 
>> ++++++++++++++++++++++++++
>>  1 file changed, 187 insertions(+), 3 deletions(-)
>>
> [...]
>> +            ret = opal_mpipl_query_tag(OPAL_MPIPL_TAG_KERNEL, &addr);
>> +            if ((ret != OPAL_SUCCESS) || !addr) {
>> +                    pr_err("Failed to get Kernel metadata (%lld)\n", ret);
>> +                    return 1;
>> +            }
>> +
>> +            addr = be64_to_cpu(addr);
>> +            pr_debug("Kernel metadata addr: %llx\n", addr);
>> +
>> +            opal_fdm_active = __va(addr);
>> +            r_opal_fdm_active = (void *)addr;
>> +            if (r_opal_fdm_active->version != OPAL_FADUMP_VERSION) {
>> +                    pr_err("FADump active but version (%u) unsupported!\n",
>> +                           r_opal_fdm_active->version);
>> +                    return 1;
>> +            }
>> +
>> +            /* Kernel regions not registered with f/w  for MPIPL */
>> +            if (r_opal_fdm_active->registered_regions == 0) {
>> +                    opal_fdm_active = NULL;
> 
> What about partial dump capture scenario ? What if opal crashes while
> kernel was in middle of registering ranges ? We may have partial dump
> captured which won't be useful.
> e,g. If we have total of 4 ranges to be registered and opal crashes
> after successful registration of only 2 ranges with 2 pending, we will get a
> partial dump which needs to be ignored.
> 
> I think check shuold be comparing registered_regions against total number of
> regions. What do you think ?

Yes, Mahesh.
Taking care of that in 22/25

Thanks
Hari

Reply via email to