Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751504AbbEFTdN (ORCPT ); Wed, 6 May 2015 15:33:13 -0400 Received: from mail-oi0-f54.google.com ([209.85.218.54]:35016 "EHLO mail-oi0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750845AbbEFTdJ (ORCPT ); Wed, 6 May 2015 15:33:09 -0400 Message-ID: <554A6C6F.4030602@acm.org> Date: Wed, 06 May 2015 14:33:03 -0500 From: Corey Minyard Reply-To: minyard@acm.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Mandeep Sandhu CC: openipmi-developer@lists.sourceforge.net, linux-kernel Subject: Re: [Openipmi-developer] Shutdown behavior with IPMI enabled References: <554A0E26.1030605@acm.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3230 Lines: 75 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/