[syslinux] [RESEND][RFC GIT PATCHES] acpioff: COM32 module to shut off machine using ACPI

Gene Cumm gene.cumm at gmail.com
Sun Mar 18 05:41:48 PDT 2012

On Sat, Mar 17, 2012 at 23:56, H. Peter Anvin <hpa at zytor.com> wrote:
> On 03/17/2012 06:51 PM, Andy Walls wrote:
>>On Sat, 2012-03-17 at 16:57 -0700, H. Peter Anvin wrote:
>>> On 03/17/2012 06:46 AM, Andy Walls wrote:
>>> > What I implemented with acpioff is not worth converting to a shared
>>> > component, in my opinion.  It is minimally functional and cannot be use
>>> > for general power management with ACPI.
>>> A much bigger issue: we can't go into ACPI system mode; that is the
>>> prerogative of the OS.
>> Oh, but I do, in acpioff.c:
> Yes, but you're turning the system off.
>> Before control is transfered to a new OS with ACPI support, SYSLINUX, or
>> PXELINUX, and the COM32 module would need to ensure the hardware is not
>> in ACPI mode, by calling acpi_terminate().
> I wouldn't trust that to work right, given that it is an uncommon
> operation and BIOSes are notoriously buggy.
>        -hpa

Instead of attempting acpi_terminate(), the only reliable operations
are to power off or reboot.  Enabling ACPI system mode needs to be
viewed as a one-way trip after which no other ACPI-enabled system can
reliably take control.  It's like moving from a Linux kernel to
Microsoft Windows NT kernel or vice versa.  Swapping between Linux
kernels can be done but only because there's a reliable way to pass

The reliability of acpi_terminate() would not only depend on the BIOS
(system and revision) but the presence or lack of hardware (add-in
peripheral, different model CPU, different amount of RAM) could easily
influence its reliability.  Based on that, even a whitelist will
likely not be sufficient for reliable operation.

At least after acpi_enable_subsystem() (and possibly earlier),
acpioff.c32 should ensure control can not be returned by performing
another power off, reboot, or a nearly unbreakable loop.  The Syslinux
core attempts multiple callback/reboot methods and then traps the
system in a nearly unbreakable loop where Ctrl-Alt-Del is normally the
only thing that can still take any action.


More information about the Syslinux mailing list