All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corey Minyard <minyard@acm.org>
To: Mandeep Sandhu <mandeepsandhu.chd@gmail.com>
Cc: openipmi-developer@lists.sourceforge.net,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [Openipmi-developer] Shutdown behavior with IPMI enabled
Date: Wed, 06 May 2015 14:33:03 -0500	[thread overview]
Message-ID: <554A6C6F.4030602@acm.org> (raw)
In-Reply-To: <CAC+QLdR-DqAkKru3bJ3Z8Bnnmzr9gmCDrwf5_YfVh6r8UmNg_A@mail.gmail.com>

On 05/06/2015 12:23 PM, Mandeep Sandhu wrote:
>>> I have access to the BMC firmware and I saw that the way BMC handles
>>> "chassis power off" is by emulating a power button press for 6
>>> seconds. But since the host already shuts down in the meantime, the
>>> button press ends up power up the system again!
>> Well that's a very unusual interpretation of "power off".
> How do you think power off should've been handled by the BMC? Should
> it have requested the BIOS to put the CPU in the power off state (S5)?
> Mine is an Intel system and I guess the kernel too requests the BIOS
> for putting the CPU in S5 state (by writing to some BIOS register).

Certainly, it should just immediately power the system off.  There is a
soft shutdown option if you want a graceful shutdown.

The spec says:

    0 - power down. Force system into soft off (S4/S45) state. This is for
    ‘emergency’ management power down actions. The command
    does not initiate a clean shut-down of the operating system prior to
    powering down the system.

I would say the system in question is not compliant, to me, 6 seconds an
"force" are not the same thing :).

>> Well, theoretically, if the power off function completes, the system
>> should be powered off and therefore nothing else should run.  So there's
>> no real provision for not calling the other power off functions.
> I went through the code of ipmi_poweroff module and it seems that the
> driver ends up replacing the "pm_power_off" function with it's own
> ipmi_poweroff_function. So I assume only the IPMI power action should
> be performed. But it seems that there's some other path during the
> shutdown sequence which also switches off the system. If I disable
> ACPI (via kernel cmdline), then the kernel power off does not happen,
> and only IPMI is used.

Yes, the ACPI power off ties in through a different mechanism.

>>> If the host can shut itself down, it should not ask the BMC to do a
>>> power off or vice-versa.
>> I"m not sure I have a great solution.  You can, of course, not use the
>> ipmi_poweroff module.  I'm not sure of the utility of it in a modern
>> system.  In the past, before reliable ACPI and such, some systems didn't
>> have reliable power off function and IPMI was the only way to accomplish
>> this in some cases.  Which is why the function exists.
> Thanks for giving a background context to the poweroff module. I
> wasn't sure why or when is it needed.
>
>> Another option would be to spin in the ipmi power off function forever.
>> I'm not sure I like that option, either.
>>
>> It might be best to remove, or at least disable normally, the config
>> option in most systems.  That way systems that really needed it could
>> have it, but it wouldn't affect most people.
> Which config option do you refer to here? Something that disables the
> IPMI power off function?

Yes, CONFIG_IPMI_POWEROFF

-corey

> Thanks for your time.
>
> Regards,
> -mandeep
>
>> -corey
>>
>>> Thanks,
>>> -mandeep


  reply	other threads:[~2015-05-06 19:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAC+QLdTO7UdoZMgPUK=hci8CR3r98VBWqmYShnWPLudCRvDgXQ@mail.gmail.com>
2015-05-06 12:50 ` [Openipmi-developer] Shutdown behavior with IPMI enabled Corey Minyard
2015-05-06 17:23   ` Mandeep Sandhu
2015-05-06 19:33     ` Corey Minyard [this message]
2015-05-06 20:34       ` Mandeep Sandhu

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=554A6C6F.4030602@acm.org \
    --to=minyard@acm.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mandeepsandhu.chd@gmail.com \
    --cc=openipmi-developer@lists.sourceforge.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.