Bug 30150 - Systems capable of software power off do not halt
Systems capable of software power off do not halt
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-01 00:21 EST by Arion Blishen
Modified: 2007-04-18 12:31 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-03-14 15:13:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
the dmesg output from my Tyan board (6.71 KB, text/plain)
2001-03-14 15:06 EST, David Lamm
no flags Details

  None (edit)
Description Arion Blishen 2001-03-01 00:21:06 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; 0.8)
Gecko/20010211


Systems capable of software power do not halt when halt or shutdown is
used. ie. the box must be manually turned off.

Happends in RH 7.0, 7.1 tryed on hardware
Intel ISP1100
ASUS CUBX Motherboard PIII

Reproducible: Always
Steps to Reproduce:
1.use halt or shutdown -h now
2.
3.
Comment 1 Bill Nottingham 2001-03-01 00:37:42 EST
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.)
Comment 2 Arjan van de Ven 2001-03-01 04:17:11 EST
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 :)
Comment 3 Arion Blishen 2001-03-02 00:09:44 EST
But for the 20% can you give the option at install time to enable it ?
Comment 4 Arjan van de Ven 2001-03-02 03:45:38 EST
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.
Comment 5 David Lamm 2001-03-08 17:37:27 EST
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!
Comment 6 Elton Woo 2001-03-09 17:14:05 EST
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.
Comment 7 Arion Blishen 2001-03-10 04:13:17 EST
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.
Comment 8 David Lamm 2001-03-11 16:33:59 EST
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.
Comment 9 Arjan van de Ven 2001-03-11 16:48:12 EST
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.
Comment 10 Takashi Miyaji 2001-03-12 20:27:01 EST
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.
Comment 11 Arion Blishen 2001-03-12 21:50:07 EST
Allt the MainBoards I listed have AWARD BIOSes and add
apm=realmaode line to lilo.conf has no effect at all
Comment 12 David Lamm 2001-03-13 02:02:43 EST
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!  :-)
Comment 13 David Lamm 2001-03-14 15:06:18 EST
Created attachment 12663 [details]
the dmesg output from my Tyan board
Comment 14 David Lamm 2001-03-14 15:13:55 EST
I have attached my dmesg output for arjanv@redhat.com.  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.
Comment 15 Arjan van de Ven 2001-03-21 13:03:48 EST
Will look into the DMI issue; I'll close this bug as there is a working
workaround for those with a broken bios.

Note You need to log in before you can comment on or make changes to this bug.