[Skiboot] [PATCH v4 14/18] fadump: Introduce new reboot type
Vasant Hegde
hegdevasant at linux.vnet.ibm.com
Thu Aug 16 15:31:12 AEST 2018
On 08/07/2018 01:29 PM, Stewart Smith wrote:
> Vasant Hegde <hegdevasant at linux.vnet.ibm.com> writes:
>> Enhance reboot2 call to support FADUMP. Payload will call this interface
>> to initiate fadump.
>>
>> Signed-off-by: Vasant Hegde <hegdevasant at linux.vnet.ibm.com>
>> ---
>> core/platform.c | 4 ++++
>> doc/opal-api/opal-cec-reboot-6-116.rst | 7 +++++++
>> include/opal-api.h | 1 +
>> 3 files changed, 12 insertions(+)
>>
>> diff --git a/core/platform.c b/core/platform.c
>> index 3282227c1..08f05dc9b 100644
>> --- a/core/platform.c
>> +++ b/core/platform.c
>> @@ -101,6 +101,10 @@ static int64_t opal_cec_reboot2(uint32_t reboot_type, char *diag)
>> case OPAL_REBOOT_FULL_IPL:
>> disable_fast_reboot("full IPL reboot requested");
>> return opal_cec_reboot();
>> + case OPAL_REBOOT_MPIPL:
>> + prlog(PR_ERR, "Kernel requested for fadump\n");
>> + assert(false);
>> + break;
>> default:
>> prlog(PR_NOTICE, "OPAL: Unsupported reboot request %d\n", reboot_type);
>> return OPAL_UNSUPPORTED;
>> diff --git a/doc/opal-api/opal-cec-reboot-6-116.rst b/doc/opal-api/opal-cec-reboot-6-116.rst
>> index 516d4fc01..11cf54aa1 100644
>> --- a/doc/opal-api/opal-cec-reboot-6-116.rst
>> +++ b/doc/opal-api/opal-cec-reboot-6-116.rst
>> @@ -63,6 +63,13 @@ OPAL_REBOOT_FULL_IPL = 2
>> On platforms that don't support fast reboot, this is equivalent to a
>> normal reboot.
>>
>> +OPAL_REBOOT_MPIPL = 3
>> + Request for fadump reboot. Firmware will reboot the system and collect
>> + dump.
>> +
>> + On platforms that don't support fadump, this is equivalent to a
>> + normal assert.
>
> I think a reboot type is the right way to go here, although I was
> thinking maybe something not tied to MPIPL itself but something a bit
> more generic....
>
> I'm thinking along the lines of "should a dump be taken"... We have
> OPAL_REBOOT_PLATFORM_ERROR for when there's something gone wrong on a
> platform level (theoretically not the Operating System's fault), maybe
> we want OPAL_REBOOT_OS_ERROR ?
Yes. OS_ERROR makes sense. Will fix it.
>
> With a dump being attempted for OPAL_REBOOT_PLATFORM_ERROR and
> OPAL_REBOOT_OS_ERROR reboot types?
By default we have disabled xscom_trigger_xstop() in P9. So
OPAL_REBOOT_PLATFORM_ERROR
will return to kernel and kernel will call panic path.
I think we should plumb panic path to call OPAL_REBOOT_OS_ERROR.
>
> A bit of an unanswered question I have is if we should have a fast
> reboot path for gathering a dump, as I'm not sure there's much that
> would prevent us doing that?
Nothing prevents us from doing it . But do we really need? My understanding is
fast reboot is called in normal path (not when we hit some kernel/platform error).
-Vasant
More information about the Skiboot
mailing list