openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Tung Nguyen OS <tungnguyen@os.amperecomputing.com>
To: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Subject: ipmi command implementation mismatch with the design document
Date: Mon, 23 Nov 2020 06:39:27 +0000	[thread overview]
Message-ID: <BL0PR01MB515650923510989237151B70FFFC0@BL0PR01MB5156.prod.exchangelabs.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 3419 bytes --]

Hi everyone,
I’m Tung Nguyen, developer for AmpereComputing - Altra system. While working with the IPMI commands I have a concern when comparing the design document and the implementation like the following:
The state-management-and-external-interfaces.md
The full mapping of Redfish and IPMI to xyz.openbmc_project.State.* is as follows:
Redfish                 IPMI                xyz.openbmc_project.State.Transition

ForceOff                power down          Chassis.Off
ForceOn                 power up            Host.On
ForceRestart            hard reset          Host.ForceWarmReboot
GracefulRestart                             Host.GracefulWarmReboot
GracefulShutdown        soft off            Host.Off
On                      power up            Host.On
PowerCycle (host on)    power cycle         Host.Reboot
PowerCycle (host off)                       Chassis.PowerCycle

the IPMI – chassishandler.cpp:

ipmi::RspType<> ipmiChassisControl(uint8_t chassisControl)

{

    int rc = 0;

    switch (chassisControl)

    {

        case CMD_POWER_ON:

            rc = initiate_state_transition(State::Host::Transition::On);

            break;

        case CMD_POWER_OFF:

            // This path would be hit in 2 conditions.

            // 1: When user asks for power off using ipmi chassis command 0x04

            // 2: Host asking for power off post shutting down.



            // If it's a host requested power off, then need to nudge Softoff

            // application that it needs to stop the watchdog timer if running.

            // If it is a user requested power off, then this is not really

            // needed. But then we need to differentiate between user and host

            // calling this same command



            // For now, we are going ahead with trying to nudge the soft off and

            // interpret the failure to do so as a non softoff case

            rc = stop_soft_off_timer();



            // Only request the Off transition if the soft power off

            // application is not running

            if (rc < 0)

            {

                // First create a file to indicate to the soft off application

                // that it should not run. Not doing this will result in State

                // manager doing a default soft power off when asked for power

                // off.

                indicate_no_softoff_needed();



                // Now request the shutdown

                rc = initiate_state_transition(State::Host::Transition::Off);

            }

            else

            {

                log<level::INFO>("Soft off is running, so let shutdown target "

                                 "stop the host");

            }

            break;



The redfish – systems.hpp:
        else if (resetType == "ForceOff")
        {
            command = "xyz.openbmc_project.State.Chassis.Transition.Off";
            hostCommand = false;
        }





Although the indicate_no_softoff_needed() can prevent the host from soft off, but it seems like a mismatch b/w the design document and the IPMI implementation.

So, my question: is it reasonable for IPMI command ?

Reference:
https://github.com/openbmc/docs/blob/master/designs/state-management-and-external-interfaces.md

Best regards,
Tung

[-- Attachment #2: Type: text/html, Size: 20099 bytes --]

             reply	other threads:[~2020-11-23 23:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-23  6:39 Tung Nguyen OS [this message]
2020-11-24 19:06 ` ipmi command implementation mismatch with the design document Vernon Mauery
2020-11-30 17:36   ` Andrew Geissler
2020-12-10  8:34     ` George Hung (洪忠敬)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BL0PR01MB515650923510989237151B70FFFC0@BL0PR01MB5156.prod.exchangelabs.com \
    --to=tungnguyen@os.amperecomputing.com \
    --cc=openbmc@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).