Bug 30150

The APM BIOS in the machine is disagreeing with the power-off calls sent
by the kernel. If it's a SMP machine, if you boot with 'apm=power-off' it
will enable the poweroff; otherwise it won't (APM is normally disabled on
SMP machines.)

If it is not a SMP box, try "APM=realmode" and see if that powers it down.
Unfortionatly, we cannot make "APM=realmode" the default as that breaks for the
other 80% of the users :)

But for the 20% can you give the option at install time to enable it ?

1) Did it fix it for you

2) It doesn't fail for 20%, my current estimate is about 1 or 2%. the other 18%
   work either way 

If you can give me your dmesg "BIOS identification" output, I might be able
to blacklist your bios to default to the "apm=realmode" as this is generally a
biosbug that requires this.

This happens for me too, and has for Redhat 6.2, 7.0, Fisher, and Wolverine. 
The difference is I get a GPF during the shutdown.

Hardware:
Tyan Trinity ATX  Model S1598
VIA chipset, K6-2 500 MHz

I don't know if the following will help, but this is the final screen I see
during shutdown.  I then have to turn off the machine manually.


Unmounting file systems:                    [  OK  ]
Unmounting proc file system:                [  OK  ]
The system is halted
stopping all md devices
Power down.
general protection fault: f000
CPU:  0
EIP:  0050:[<00008895>]
EPFLAGS:  00010046
eax: 00005301   ebx: 00000001   ecx: 00000000   edx: 00000000
esi: c0248146   edi: c73f3e8c   ebp: 67890000   esp: c73f3de0
ds: 0058   es: 0000   ss: 0018
Process halt (pid:12522, stackpage=c73f3000)
Stack (stuff here)
CallTrace (stuff here)

Code: badEIPvalue
/etc/rc0.d/s01halt: line1: 12522 segmentation fault  halt -i -d -p


I hope this helps!  I will try the "APM=realmode" as well.  If there is any
other information you need, just ask!

I have noticed this problem has _only started_ since I've installed the latest
updated packages
via up2date, and the newer 2.4.2-0.1.19 kernel . Previous to this, I was able to
power OFF the machine by invoking shutdown either as root or as user (Wolverine
beta).
My system: Acer Open AX59Pro, BIOS Rev. 2.35 with AMD-k6/2-500 CPU.

Typing
apm=realmode
or 
apm=poweroff

at the prompt does has no effect the boxes still just get a message like
Power Off
System Halted etc

Have same problem on 
ASUS K7V Bios 1007 (VIA KX133) Athlon 750MHz
Intel ISP1100 Bios Rev 9 (uses Intel BX MainBoard)
ASUS CUBX Bios 1006 (BX MainBoard)

I haven't actually seen a RedHat box power off in a long time even some laptops
This has been the case for all RH version since at least 6.2

If extra options are required to make a box power off at shutdown just give the
user the option in anaconda when installing

Thanks.

Using the "apm=realmode" at the command line does not work for my Tyan board. 
Is this the correct place to issue the command and is the syntax correct?
Looking at the "man" pages for the APM Daemon do not provide any additional help
either.

I have been trying to research this problem, and based on the following web
sites and bug lists, "http://linuxcare.com.au/apm/" and
"http://www.worldvisions.ca/~apenwarr/apmd/index.html" it would appear that this
poweroff problem is usually associated with BIOSs from Award Software
International.  From what I can gather, they do not properly execute the
"Protected Mode" call to poweroff the system.  They require a "Real Mode" call.

I have also determined that the APM Daemon does have a "Real Mode" boot time
option, but neither site describes the steps to set this!  If we can figure this
out, and it works, I would propose adding a comment to the "man" page, and
Redhat's FAQ so people can set this manually.

A more complicated solution could be used, but I suspect this problem will
become moot when the Advanced Configuration and Power Interface (ACPI) Daemon
becomes finalized.  From what I can tell from
"http://linux.oreilly.com/news/lnxkernel_1100.html" this will eventually replace
APMD.

....ok, enough rambling... thanks for your patience.

apm=realmode is actually a LILO option, not an apmd option.
You can add this by having a 
append="apm=realmode" 
in your lilo.conf entry for the kernel.

This occureed my PC, too.

MotherBoard: CHAINTECH 6WPV M101
CPU:         Pentium Celeron 433Mhz
BIOS:        AWARD Modular BIOS V6.00PG
Linux Ver:   2.2-16

According advice, described in here, I changed /etc/lilo.conf.
But, I could not avoid segmentation fault.

So, I rebuilt kernel with "apm=realmode" and installed.
It worked fine, and BOX power was down automatically.

I give thanks to all who descuss about this problem.
I will be able to sleep well from now.

Allt the MainBoards I listed have AWARD BIOSes and add
apm=realmaode line to lilo.conf has no effect at all

You may be putting the append option in the wrong place.  Here's a copy of my
lilo.conf file that does shutdown properly.

-------------------------------
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
message=/boot/message
linear
default=linux

image=/boot/vmlinuz-2.4.2-0.1.25
         label-linux
         read-only
         root=/dev/hda5
         append="apm=realmode"

---------------------------------

Don't worry about whether or not the other lines are exactly the same as this. 
Just note where the append command is and the syntax of that line.

The next thing you MUST do (as root user) is run "lilo" at the command prompt. 
This will actually make the changes that you made to "lilo.conf" take effect. 
If you get any error messages then check your syntax carefully!

The next time you start the system, the "shutdown -h" command should properly
power off.

Oh, I learned about using the append and lilo commands the hard way some months
ago!  :-)

Created attachment 12663 [details]
the dmesg output from my Tyan board

I have attached my dmesg output for arjanv.  Perhaps the "blacklist"
idea is the best for now.  Although, I think the DMI module, which displays BIOS
information, may not be compiled into the kernel.  My motherboard is compliant
with the DMI 2.x spec, but it's not being displayed/detected in the dmesg output.

Will look into the DMI issue; I'll close this bug as there is a working
workaround for those with a broken bios.