This is probably a kernel problem in how it reboots the machine; the associated
code in SysVinit hasn't changed.

Might be ACPI related. (However, using an older kernel, my Asus A7V powers 
down nicely).

I think it is a kernel problem but it may also be an init problem or a glibc
problem.  I was about to report a similar bug but found this in my query. 
Here's some additional input.  I have an ASUS P2B-LS motherboard with BIOS
revision 1012.  It is APM and ACPI-compliant.  The kernel reports:

apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14)

/proc/apm looks sensible, apmd works, etc.

halt -p results in loss the kernel printing "Power Down" and in keyboard input
not working anymore, but power does not go off.  I've always been able to power
down this way in previous releases.

If I boot into single user mode and do this:

umount -a -t noproc
mount -o ro,remount /
strace halt -f -p

the strace output ends with the following:

reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
       LINUX_REBOOT_CMD_RESTART|0x88888888) = 0
kill(1, SIGTSTP)
reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
       LINUX_REBOOT_CMD_POWER_OFF)

Perhaps the first line explais why the original reporter of this bug gets a
reboot.  I haven't looked at the init code to see what it's actually doing or
whether this code comes from something in glibc.  Looking at the reboot(2)
manual page and doing what it says results in EINVAL from reboot().  Perhaps the
documentation is out of date or I did it wrong.  The manual page shows reboot()
having four arguments, but strace only shows three.  Hopefully this additional
information will provide some more clues.

We (Red Hat) should really try to fix this before next release.

Same problem with MSI 6195 (K7Pro) motherboard...

===
 halt -p results in loss the kernel printing "Power Down" and in keyboard input
 not working anymore, but power does not go off.  I've always been able to power
 down this way in previous releases.
===
Sounds like ACPI to me.

As ACPI was mentioned, I restarted the system with the
kernel parameter "apm=off"

This results in the following on boot:
 kernel: ACPI: System description tables found
 kernel: ACPI: System description tables loaded
 kernel: ACPI: Subsystem enabled
 kernel: ACPI: System firmware supports: C2
 kernel: ACPI: System firmware supports: S0 S1 S3 S4 S5

With this configuration, attempts to power down with "poweroff" etc. result in
the usual power down display ending with:

Power down
ACPI: S5 failed

Then the system is locked and must be reset or powered off manually.

"ACPI: S5 failed" says basically "Ehhh your bios is borked."
Now, this can be the Bioses fault, or a bug in the ACPI code.

We are no longer building ACPI support into the kernel, so
this should go away in future kernels.

*** Bug 26444 has been marked as a duplicate of this bug. ***

Re: this going away when ACPI is no longer built into the kernel

I know those of you working on this have more clue than I do. Would you help me
understand why you think this is an ACPI issue?

As I understand the log file in the original post, ACPI exits because "APM is
already active" It's not until I turned of APM that I received an actual ACPI error.

Also, for what it's worth, I just built a kernel WITHOUT ACPI support. The
problem is still there. If you care to send me a .config with your build
preferences I would be happy to build a kernel and test it on this hardware.

I hope someone will reopen this bug.  I can't since I was not the poster.

I tried poweroff with the rawhide 2.4.0.99-23 kernel (no ACPI support) and with
2.4.1 (with ACPI).  The behavior is unchanged -- on my ASUS P2B-LS rev 1012, I
still do not get power down -- just the message and locking keyboard.

Somewhere along the line this was flagged as an ACPI issue. The "fix"  then
became the fact that ACPI support will no longer be included in the kernel builds.

Two of us have built kernels without ACPI support yet the problem is still there.

Could we please take another look at this one?

Ok. Not an ACPI issue. The difference between the 7.0 kernel and the
fisher kernel is that the 7.0 kernel has "REAL_MODE_POWEROFF" disabled,
while the fisher kernel has it enabled. It would be real helpful if
someone can confirm changing this option fixes this bug for them.

This worked for my system, ASUS K7V ACPI BIOS Revision 1007

1) Built quick/dirty kernel:
  Created .config using the defaults from "make xconfig".
  The only change from the defaults was
  # CONFIG_APM_REAL_MODE_POWER_OFF is not set
  Built a bzImage.  Did NOT build/install modules

2) Booted with test kernel.

3) poweroff and init 0 work as expected.

Thanks for testing + confirming this. Newer kernels will have this change.

I'll test this tonight when I'm at home -- testing power off remotely is pretty
hard! :-) I'll report back with the result regardless.

Building a kernel with REAL_MODE_POWEROFF disabled worked for me too.  Thanks. 
Just for kicks, I also disabled ACPI, so both of these being off works in my
case.

Ok. That's enough for me. REAL_MODE_POWEROFF is gone for the next build that
will appear in Rawhide.

I reported this to the Wolverine list, and am adding a comment here, in the
hopes that it would
be of use to the development team. My system: AOPEN AX59PRO ATX, rev. 2.35. 
Since installing
the latest updates (including the 2.4.2-0.1.19 kernel), I can halt the system,
but not power *off*.

What was the last working kernel ?
and could you please try adding
append="apm=realmode"
to the lilo.conf file ?

The previous working kernel that I had in Wolverine was 2.4.1.-0.1.9  For
the moment, I cannot report on the success or failure WRT the amendment to my
lilo.conf file, which I have edited per your suggestion.

My lilo.conf now contains:

image=/boot/vmlinuz-2.4.2-0.1.19
	label=linux
	initrd=/boot/initrd-2.4.2-0.1.19.img
	read-only
	root=/dev/hda5
	append="scd0=ide-scsi apm=realmode"

Still no luck. A "shutdown" merely terminates all services, but does NOT power
off
the machine.

I've just upgraded to kernel 2.4.2.-0,.1.25. The system now powers off without
the need
to add "apm=realmode" ro my lilo.conf.