From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.7.2) Gecko/20040803 Description of problem: system report ACPI_POWER_OFF CALLED but don't go off. No error was reported, but work well in vanilla kernel 2.6.7 and the system power off correctly. Version-Release number of selected component (if applicable): FC2 Kernel 2.6.8-1.520 How reproducible: Always Steps to Reproduce: 1.call poweroff of shutdown -h now Actual Results: ACPI_POWER_OFF CALLED is the last message - to power of the machine - I pressed for 5 sec the power off buttom. Additional info:
Created attachment 103922 [details] last dmesg
Created attachment 103923 [details] last messages
Created attachment 103924 [details] lspci -vv
Created attachment 103925 [details] dmidecode
Created attachment 103926 [details] acpidmp
Is bug 134183 a duplicate of this one? Poweroff works for me in FC2, but haven't worked for the last month or so in Rawhide.
*** Bug 134183 has been marked as a duplicate of this bug. ***
*** Bug 135218 has been marked as a duplicate of this bug. ***
*** Bug 136673 has been marked as a duplicate of this bug. ***
Same comment as the one above in relation to bug 135218 - are you sure this is a duplicate? I had no problems with this on FC2 at all (kernels up to and including 2.6.8-1.521). The problems started in 2.6.8-1.603. Before that, FC3 test/development line worked fine too.
*** Bug 137303 has been marked as a duplicate of this bug. ***
*** Bug 137701 has been marked as a duplicate of this bug. ***
Bug present in FC3rc5 - fresh install on Abit KT7A-RAID, Athlon 1GHz.
Have poweroff problem with Thinkpad A22p that started with the installation of 2.5.8-1.521 kernel. Also getting error with mdmpd: Kernel md does not support events. /var/log/messages does not show any unusual activity other than above.
I am experiencing the same problem with my HP Pavillion ze4805us. Problem started with the upgrade to FC3 and kernel version 2.6.9-1.667. It worked previously in FC2 and kernel version 2.6.8-1.521 and earlier without incident.
Noticed the same problem too on my HP nx9010. FC2 was fine but not FC3.
Im having the same problem with my computer since upgrading to FC3 from FC2. My BIOS is AWARD BIOS v6.00PG. My Motherboard is MSI KM3M-V. Shutdown worked correctly in FC2 with the latest kernel (2.6.8).
I confirm this bug in FC3. I'm using an ASUS LC5 laptop. FC1 and FC2 always did shutdown properly. Starting from kernel 2.6.9-1.667 (after upgrade FC2 -> FC3), shutting down stops with message "acpi_power_off funcion called".
Same problem on an ECS k7vta3 with fresh install of FC3. Last message is "acpi_power_off funcion called", but system does not power off.
On a ThinkPad A22p with a default FC3 install (kernel 2.6.9-1.667), I had the exact same problem. So I edited /etc/inittab: #ca::ctrlaltdel:/sbin/shutdown -t3 -r now ca::ctrlaltdel:/sbin/shutdown -h now and now the laptop shuts down correctly when using the CTL-ALT-DEL sequence.
*** Bug 138781 has been marked as a duplicate of this bug. ***
Just a 'me too' on this one. My Latitude L400 laptop was fine with FC2 but since installing FC3 it won't power off after shutdown. It goes into some mode where the disk and screen are powered off but the power light remains on and I have to press the power button for 5 seconds to get it to really turn off.
Yet another 'me too'. I have a Abit KG7-RAID motherboard which has AMD761/VIA 686B chipset. My CPU is an AMD Thunderbird 1400MHz. After upgrading from FC2 to FC3 it no longer shuts down and just freezes after displaying "acpi_power_off called.
Yup, me as well, running an Athlon XP with a Soyo motherboard. Everything was fine in Fedora Core 2, but Core 3 gives me this problem.
Hello, please refer to this ID, the problem solve : id=137701 Armel
IMHO the workaround in bug 137701 is no solution because disabling the acpi support does not fix the underlying bug.
Of course it isn't and neither is the inittab thing from a few posts up.
*** Bug 139402 has been marked as a duplicate of this bug. ***
*** Bug 139284 has been marked as a duplicate of this bug. ***
*** Bug 139211 has been marked as a duplicate of this bug. ***
I confirm this bug in FC3. I'm using an Asus motherboard. FC1 and FC2 always did shutdown properly. Starting from kernel 2.6.9 (after upgrade FC2 -> FC3), shutting down stops with message "acpi_power_off funcion called". Agreed that turning off ACPI doesn't solve the problem. See, when this happens, I have to reboot the computer to shut it off, because the power button won't turn the machine off, I have to shut it off from the back. So its really an inconvience at times.
Just changed my kernel line in grub.conf to kernel /vmlinuz-2.6.9-1.667 ro root=LABEL=/1 acpi=ht (don't care for "rhgb quiet") based on Comment #4 in BZ 139211, rebooted, shut down, and achieved power off! Now, can anyone explain why this works? My machine is a plain Athlon - not hyperthreaded.
Yet another me-too report: With FC2, I had no problem powering off, but with FC3, poweroff shuts down but doesn't power off. About comment #32: Setting acpi=ht simply turns off ACPI here: Machine makes lots of noise, and /proc/acpi doesn't exist. So that's certainly not a solution here. (Actually, I believe that it may be damaging on some systems if ACPI is turned off, due to overheating.) My hardware: ASUS M2400 series laptop. CPU: Pentium 4 mobile. lspci: 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 650/M650 Host (rev 01) 00:01.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to-PCI bridge (AGP) 00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS961 [MuTIOL Media IO] (rev 10) 00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller 00:02.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 07) 00:02.3 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 07) 00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) 00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] Sound Controller (rev a0) 00:03.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 90) 00:0a.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev a8) 00:0a.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev a8) 00:0a.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller 00:0c.0 Communication controller: Conexant HSF 56k HSFi Modem (rev 01) 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 65x/M650/740 PCI/AGP VGA Display Adapter
my machine isn't hyperthreading either, yet it works on mine too. I was the one that made that comment. you don't have to use rhgb and quiet, thats just what my config is, actually I took out rhgb too. I was just saying where to put it. not sure why this works either, I would like to know as well
I have a HP Kayak with 2 Pentium in it. Since I moved to FC1 to FC3 poweroff doesnt work anymore when using the SMP kernel. However if I used the non-SMP kernel the poweroff works well. I assumed that I'm not using ACPI but APM which is not SMP safe. However in the past there where an hack in the apm stack to allow the poweroff. We can assume that when initiating a power-off there is not so much stuff going on, and one processor could be desactivated. I have tested to change grub.conf by adding apm=power-off. When doing that I'm getting a Panic message: mkrootdev: label / not found mount: error 2 mounting ext3 mount: error 2 mounting now switchroot: mount failed 22 umount /initrd/dev failed 2 kernel panic
The acpi=ht doesn't work (i.e. doesn't power off) on my ZE4201, P4-based Celeron. Latest kernel, 2.6.9-1.678_FC3 still has the same problem.
*** Bug 140028 has been marked as a duplicate of this bug. ***
hi! i had the same problem on my laptop (Acer Ferrari 3000, kernel 2.6.9-1.649). it's an ACPI bug: http://bugme.osdl.org/show_bug.cgi?id=3669 There is a patch available: http://bugme.osdl.org/attachment.cgi?id=4034&action=view Have fun ;)
I have this problem also. Since I recently applied upgrades to the BIOS from the vendor of the laptop, I thought that these upgrades broke the acpi shutdown. I run with acpi=on in the grub.conf file. This laptop is an HP ze4315us. I'm not sure if this is important, XP shuts down without problems. I have to hold the power button in to shut off power.
Created attachment 107111 [details] filtered shutdown boot.log messages Checking the log files for boot and other system messages, I dscovered that the log was not written because of SELinux and my upgrade path. Severn until present FC3 system. Attached is the filtered boot.log for shudown messages. Since the log was shutoff because of a need to relabel my system and get SELinux working right, there is a time reference where things were correctly running. This might aid in referencing the kernel time related changes, in order to isolate the problem. SELinux is of course disabled, otherwise there would be no boot.log written.
*** Bug 140199 has been marked as a duplicate of this bug. ***
Created attachment 107132 [details] Looks like somebody broke ACPI in FC3 - lspci output Another mee too. Using a Shuttle PC with AMD XP 2200, 512MB, and SATA disks. FC3 loaded with 2.6.9-1.681_FC3 test kernel. System shuts down and hangs at "acpi_poweroff called". Must hold down power button for 5 seconds to poweroff machine. Looks like somebody broke ACPI in FC3.
Created attachment 107133 [details] dmesg
Sorry, this text goes with Comment #44 Don't know if this adds any important information or not, but I am running FC2 with the latest kernel 2.6.9-1.3_FC2, and this upgrade caused this bug on my system. Just in case people thought this was related to FC3 alone I thought I would report this. Can anyone confirm a way to fix this bug? I see several work arounds. Before I spend any time doing one or the other, which should I do? Should I wait for an upgrade? Dan.
I was told that the 2.6.9 kernel has some serious bugs anyway, so why fedora decided to use it is beyond me. alot of people are saying the 2.6.9 kernel has some problems other then this, so that could be alot of it right there.
*** Bug 140231 has been marked as a duplicate of this bug. ***
Same problem on a Gigabyte K8VXNP (VIA K8T800) motherboard in 32-bit mode here. It works with apm enabled, apmd running, acpi=off. When acpi is on and I use the poweroff command the system hangs at the Power down_ message. grep ACPI /var/log/messages.1 (when I had acpi enabled / not explicitly disabled) Nov 16 20:57:57 castor kernel: BIOS-e820: 000000003fff0000 - 000000003fff3000 (ACPI NVS) Nov 16 20:57:57 castor kernel: BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data) Nov 16 20:57:57 castor kernel: ACPI: PM-Timer IO Port: 0x4008 Nov 16 20:57:57 castor kernel: ACPI: IRQ9 SCI: Level Trigger. Nov 16 20:57:57 castor kernel: ACPI: Subsystem revision 20040816 Nov 16 20:57:57 castor kernel: ACPI: Interpreter enabled Nov 16 20:57:57 castor kernel: ACPI: Using PIC for interrupt routing Nov 16 20:57:57 castor kernel: ACPI: PCI Root Bridge [PCI0] (00:00) Nov 16 20:57:57 castor kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 6 7 *10 11 12) Nov 16 20:57:57 castor kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 6 7 10 *11 12) Nov 16 20:57:57 castor kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 6 7 10 *11 12) Nov 16 20:57:57 castor kernel: ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 6 7 10 11 12) *0, disabled. Nov 16 20:57:57 castor kernel: ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 6 7 10 11 12) *0, disabled. Nov 16 20:57:57 castor kernel: ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 6 7 10 11 12) *0, disabled. Nov 16 20:57:57 castor kernel: ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 6 7 10 11 12) *0, disabled. Nov 16 20:57:57 castor kernel: ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 6 7 10 11 12) *0, disabled. Nov 16 20:57:57 castor kernel: ACPI: PCI Interrupt Link [ALKA] (IRQs 20) *0, disabled. Nov 16 20:57:57 castor kernel: ACPI: PCI Interrupt Link [ALKB] (IRQs 21) *0, disabled. Nov 16 20:57:57 castor kernel: ACPI: PCI Interrupt Link [ALKC] (IRQs 22) *0, disabled. Nov 16 20:57:57 castor kernel: ACPI: PCI Interrupt Link [ALKD] (IRQs 23) *0, disabled. Nov 16 20:57:57 castor kernel: PCI: Using ACPI for IRQ routing Nov 16 20:57:57 castor kernel: ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 Nov 16 20:57:57 castor kernel: ACPI: PCI interrupt 0000:00:0a.0[A] -> GSI 11 (level, low) -> IRQ 11 Nov 16 20:57:57 castor kernel: ACPI: PCI interrupt 0000:00:0a.1[A] -> GSI 11 (level, low) -> IRQ 11 Nov 16 20:57:58 castor kernel: ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10 Nov 16 20:57:58 castor kernel: ACPI: PCI interrupt 0000:00:0c.0[A] -> GSI 10 (level, low) -> IRQ 10 Nov 16 20:57:58 castor kernel: ACPI: PCI interrupt 0000:00:0f.0[B] -> GSI 11 (level, low) -> IRQ 11 Nov 16 20:57:58 castor kernel: ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11 Nov 16 20:57:58 castor kernel: ACPI: PCI interrupt 0000:00:0f.1[A] -> GSI 11 (level, low) -> IRQ 11 Nov 16 20:57:58 castor kernel: ACPI: PCI interrupt 0000:00:10.0[A] -> GSI 10 (level, low) -> IRQ 10 Nov 16 20:57:58 castor kernel: ACPI: PCI interrupt 0000:00:10.1[A] -> GSI 10 (level, low) -> IRQ 10 Nov 16 20:57:58 castor kernel: ACPI: PCI interrupt 0000:00:10.2[B] -> GSI 11 (level, low) -> IRQ 11 Nov 16 20:57:58 castor kernel: ACPI: PCI interrupt 0000:00:10.3[B] -> GSI 11 (level, low) -> IRQ 11 Nov 16 20:57:58 castor kernel: ACPI: PCI interrupt 0000:00:10.4[C] -> GSI 11 (level, low) -> IRQ 11 Nov 16 20:57:58 castor kernel: ACPI: PCI interrupt 0000:00:12.0[A] -> GSI 10 (level, low) -> IRQ 10 Nov 16 20:57:58 castor kernel: ACPI: PCI interrupt 0000:00:13.0[A] -> GSI 11 (level, low) -> IRQ 11 Nov 16 20:57:58 castor kernel: ACPI: PCI interrupt 0000:00:14.0[A] -> GSI 10 (level, low) -> IRQ 10 Nov 16 20:57:58 castor kernel: ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 10 (level, low) -> IRQ 10 Nov 16 20:57:58 castor kernel: apm: overridden by ACPI. Nov 16 20:57:58 castor kernel: ACPI: Processor [CPU0] (supports C1) Nov 16 20:57:58 castor kernel: ACPI: PCI interrupt 0000:00:0f.1[A] -> GSI 11 (level, low) -> IRQ 11 Nov 16 20:57:58 castor kernel: ACPI: (supports S0 S3 S4 S5) Nov 16 20:57:58 castor kernel: ACPI wakeup devices: Nov 16 20:57:58 castor kernel: ACPI: PCI interrupt 0000:00:0f.0[B] -> GSI 11 (level, low) -> IRQ 11 Nov 16 20:57:59 castor kernel: ACPI: PCI interrupt 0000:00:12.0[A] -> GSI 10 (level, low) -> IRQ 10 Nov 16 20:57:59 castor kernel: ACPI: PCI interrupt 0000:00:0c.0[A] -> GSI 10 (level, low) -> IRQ 10 Nov 16 20:57:59 castor kernel: ACPI: PCI interrupt 0000:00:10.4[C] -> GSI 11 (level, low) -> IRQ 11 Nov 16 20:57:59 castor kernel: ACPI: PCI interrupt 0000:00:10.0[A] -> GSI 10 (level, low) -> IRQ 10 Nov 16 20:57:59 castor kernel: ACPI: PCI interrupt 0000:00:10.1[A] -> GSI 10 (level, low) -> IRQ 10 Nov 16 20:57:59 castor kernel: ACPI: PCI interrupt 0000:00:10.2[B] -> GSI 11 (level, low) -> IRQ 11 Nov 16 20:57:59 castor kernel: ACPI: PCI interrupt 0000:00:10.3[B] -> GSI 11 (level, low) -> IRQ 11 Nov 16 20:57:59 castor kernel: ACPI: PCI interrupt 0000:00:14.0[A] -> GSI 10 (level, low) -> IRQ 10 Nov 16 20:57:59 castor kernel: ACPI: Power Button (FF) [PWRF] Nov 16 20:57:59 castor kernel: ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 10 (level, low) -> IRQ 10 Nov 16 20:57:59 castor kernel: ACPI: PCI interrupt 0000:00:13.0[A] -> GSI 11 (level, low) -> IRQ 11 I have tried booting with acpi=ht but that had no effect.
The same problem with a HP Compaq NX9005 after upgrading from Fedora Core 1 to Fedora Core 3.
This problem still seems to exist in 2.6.9-1.681_FC3 on my machine (HP Pavilon ze4805us) Does anyone know where I can find the release notes/CHANGELOG for the Fedora packaged kernels?
$ rpm --changelog -q kernel-<whatever-version>
Does the patch in http://bugme.osdl.org/show_bug.cgi?id=3669 help? It works for many systems for similar issues.
@Comment 52: Applying this patch to kernel-2.6.9-1.643 on FC3test3 does *not* fix the problem (sorry, no FC3 installed on this machine yet). (motherboard ECS Elitegroup K7S5A)
*** Bug 140773 has been marked as a duplicate of this bug. ***
*** Bug 140219 has been marked as a duplicate of this bug. ***
Having same problem on three of four systems I have installed FC3 on. Running 2.6.9-1.681_FC3 kernel on all of them. The machine that works is a Dell Latitude C800 (laptop) that was upgraded from FC2. The machines that do not work are: 1) Dell Optiplex GX260 (Upgraded from FC2) 2) Home built: AMD 1600+, ECS K7S5A (fresh FC3 install) 3) Home built: Duron 1300, ECS K7S5A-PRO (fresh FC3 install) Duron 1300 system used to run FC2 and the last kernel update there (the one that introduced 2.6.9 I think) also failed to power off (as reported above).
I'm not sure bug 132761 called a duplicate of this one, since the issue for me didn't start till the 2.6.9 kernels in FC2. In FC2 with kernel 2.6.8-1.521 I had no problem with poweroff working as expected every time. When I tried upgrading to the FC2 2.6.9-1.3_FC2 kernel or the 2.6.9-1.6_FC2 kernel the poweroff started failing. So there is a specific difference between the 2.6.8 kernels and the 2.6.9 kernels that broke poweroff on some systems. I currently see this issue on My Sharp MM20 laptop with the Transmetta Efficeon processor.
acpi=off does fix the problem, so what difference does it make? why do we need acpi if turning it off fixes the problem?
Answer to #58: because laptops as for example mine Fujitsu Siemens C1110D needs acpi for the fan to work properly, and even to shut down at all (no APM-support in this laptop).
Answer to #58, with out ACPI my laptops battery life would disappear, heat would become an issue, I couldn't use any form of suspend, couldn't check on remaining battery time, etc.... acpi=off is fine for many desktops, but that would be as good as saying fedora core 2/3 can never be used on laptops. As laptops are a quickly growing segment of the computer world in business as well as personal use, this isn't a good solution.
I have the same problem with my Albatron KX600 PRO motherboard (VIA KT600 chipset). Everything was ok with FC2. I was trying to make a custom kernel (with the latest 2.6.10-rc2 kernel) to check if it solves the issue, but the special initrd requirements didn't allow me to do so... Looking forward for a solution (or a new kernel?).
*** Bug 141025 has been marked as a duplicate of this bug. ***
Any more test results for the latest patch here?: http://bugme.osdl.org/show_bug.cgi?id=3669
Same problem here my pc wont shutdown completely. In the bios under >Power Magament >ACPI= enabled. But If I disable it shut power offs completely by addind acpi=off in the kernel line. This happens with latest kernels for fc2 (installed in laptop) and fc3 in desktop.
In addition to poweroff problem described above there is a problem with wakeup on interrupt. If acpi is off then the box will lights out and fan poweroff, butit will not wakeup on a network wakeup packet. This tells me that the wrong bit is being yanked on poweroff (OK different from previous). Earlier FC2 kernels and the new Solaris10x86 beta do the wakeup just fine. Both current FC2 and current FC3 kernels have this difference from previous functionality. In the case where the box stops at "ACPI_POWER_OFF CALLED" I have noted that the disks power off (I can hear the heads seek) but CDROM drives in the same box do not poweroff and the power supply does not poweroff. By chance is the processor being halted when there are scheduled ACPI events ending?
Just a data point I didn't find anyone else made: Alt+SysRq+O worked for me on the same machine that normal powering off didn't (I had one dubious "umount didn't work, retrying", became impatient, did Alt+SysRq+(S,U,O).
NB: This is kernel-2.6.9-1.681_FC3.
I tried the patch at http://bugme.osdl.org/show_bug.cgi?id=4105, specifically http://bugme.osdl.org/attachment.cgi?id=4105&action=view, but it didn't seem to work for me when applied to kernel-2.6.9-1.681_FC3. This is on a Compaq model 2199US laptop on which all previous acpi_power_off calls have shut the system off. However, it seems to have worked for enough other people that the bug has been marked closed and the patch is in the upstream 2.6.10 kernel.
Thanks for confirming the fix in osdl 3669 did not help your system. how about this one? http://bugme.osdl.org/show_bug.cgi?id=3642
sigh... I tried the acpi=off on my desktop, and it does fix the power off problem, but sadly kills my network card (network can't be found, network unreachable etc...). Here is my network card details... $ system-config-network-cmd DeviceList.Ethernet.eth0.AutoDNS=true DeviceList.Ethernet.eth0.HardwareAddress=00:e0:18:48:a4:a1 DeviceList.Ethernet.eth0.Type=Ethernet DeviceList.Ethernet.eth0.IPv6Init=false DeviceList.Ethernet.eth0.BootProto=dhcp DeviceList.Ethernet.eth0.Device=eth0 DeviceList.Ethernet.eth0.OnBoot=true DeviceList.Ethernet.eth0.DeviceId=eth0 DeviceList.Ethernet.eth0.AllowUser=false HardwareList.Ethernet.eth0.Status=ok HardwareList.Ethernet.eth0.Name=eth0 HardwareList.Ethernet.eth0.Type=Ethernet HardwareList.Ethernet.eth0.Card.ModuleName=8139too HardwareList.Ethernet.eth0.Description=RTL-8139/8139C/8139C+ ProfileList.default.ActiveDevices.1=eth0 ProfileList.default.HostsList.1.IP=127.0.0.1 ProfileList.default.HostsList.1.Hostname=localhost.localdomain ProfileList.default.HostsList.1.AliasList.1=localhost ProfileList.default.HostsList.2.IP=193.60.81.187 ProfileList.default.HostsList.2.Hostname=beta.mrc-dunn.cam.ac.uk ProfileList.default.HostsList.2.AliasList.1=beta ProfileList.default.DNS.SecondaryDNS=194.168.8.100 ProfileList.default.DNS.SearchList.1=cmbg.cable.ntl.com ProfileList.default.DNS.Domainname= ProfileList.default.DNS.Hostname=localhost.localdomain ProfileList.default.DNS.TertiaryDNS= ProfileList.default.DNS.PrimaryDNS=194.168.4.100 ProfileList.default.Active=true ProfileList.default.ProfileName=default Here are my details... $ uname -a Linux cpc2-cmbg1-4-0-cust179.cmbg.cable.ntl.com 2.6 Why is a fix for this bug so long in coming? whine whine whine
The problem goes away for me when I use a kernel based on the pristine 2.6.10-rc3 sources.
FYI: kernel-2.6.9-1.715_FC3 is still exhibiting this problem
I find the problem a bother. I would suggest leaving acpi active and holding down the power button for a short time to power off the computer and still have networking and other acpi advantages. If the next generation kernel 2.6.10 fixes the problem, it should not be too long for power off to work right again.
The poweroff part of this goes away for me with a 2.6.10-rc3 kernel. I still have not recovered the wakeup on lan magic packet function that I have grown to like. No powerup on reset, Power button OK. VIA chip set; AMD processor; -- more details -- just ask.
Vanilla kernel 2.6.10, compiled with default Fedora config file (i.e. make menuconfig (save), make, make modules_install) does power my notebook off (HP Pavilion ZE4201). So, I'm guessing when the next FC3 kernel hits the streets, we should be OK ;-)
The latest kernel that is in rawhide is a 2.6.10 series and you can shutdown properly. My HP ze4315us computer did not poweroff with the latest FC3 kernel. This is expected behavior for any 2.6.9 series kernel for certain hardware. HP laptops seem to be one of the fallout hardware for poweroff problems.
I can confirm that my notebook (HP Pavilion ZE4201) powers off with kernel-2.6.10-1.1063_FC4.
I only have kernel-2.6.9-1.667 and I cannot get past grub. Acpi=off does not let me boot and I am a bit stuck. How can I force a boot?
From the perspective of this bug, kernel-2.6.10-1.727_FC3 is good to go. Powers off my box nicely :-)
Same here. The 2.6.10-1.727 kernel powers down my Gigabyte K8VNXP. The latest 2.6.9 revision does not.
In regards to comment #78 - If you install the 2.6.10 kernel version from the FC3 testing repository and enable acpi=on - you should be able to boot. I reqiure acpi to be enabled for my laptop. The 2.6.10 kernel works fine for this purpose. (getting the computer to work right) Jim
I'm another person who experienced this problem with 2.6.9 (and maybe 2.6.8 but I don't remember for sure) but who is no longer seeing it with 2.6.10. Just mentioning it for what it's worth...
May be related... davej mentioned that large ACPI changes went into 2.6.10.
On my FC2 Sharp MM20 laptop, a 2.6.10-1.8_FC2 kernel compiled on the system using the src rpm of kernel-2.6.10-1.1063_FC4.src.rpm can again poweroff (but of coruse it introduces a whole bunch of other issues..). So the 2.6.10 kernels seem to be the right path to fix this on Fedora Core 2 on my system.
*** Bug 144445 has been marked as a duplicate of this bug. ***
with 2.6.10-1.727 i have the same problems: ACPI_POWER_OFF CALLED is the last message - to power of the machine - I pressed for 5 sec the power off buttom. grub.conf boot option | booting | power off =======================|=========|========== | yes | no -------------------------------------------- apm=power_off acpi=off | no | no -------------------------------------------- apm=power_off acpi=on | yes | no -------------------------------------------- acpi=off | no | no CMDL ============================================ poweroff | | no -------------------------------------------- shutdown -h now | | no
Ok, I've now read through all the comments here, and I think there are at least *three* separate bugs being discussed: 1. The bug originally reported here by Martin 2. http://bugme.osdl.org/show_bug.cgi?id=3669 3. The powerdown bug that's hitting lots of FC2->FC3 upgrades, as well as people who are keeping up with the FC2 kernel updates. Yesterday I narrowed down the cause of #3 so it's no longer a total mystery (it's coming from a kexec patch which Dave Jones happened to drop from the Fedora kernel simultaneously with the update from 2.6.9 to 2.6.10). To really make sure this bug gets killed for good, I need to regression-test kernel 2.6.10-mm2 (and also look into 2.6.9-x.EL); it's high on my priority list, but it's been bumped down by a few other things so I may not get to it for another day or two. Regarding #1, Martin, you may want to try updating your BIOS if you have not done so already. I split the URL into 3 lines to make sure I don't make this bug too wide: http://www.msicomputer.com/support/bios_result.asp? platform=Intel&model=875P%20Neo-LSR/FIS2R%20(MS-6758%20PCBv1)& newsearch=1
#Barry, BIOS is already upgrated to Version 2.40
I just updated my FC3 to use the recently released kernel 2.6.10-1.737_FC3, and now it properly powers down. Great! From my point of view, the bug can be closed now (but of course, we need to hear from people with other hardware).
As I mentioned in comment #87, the original reporter's shutdown problem seems to be different than everyone else's. If this bug gets closed, the original reporter will need to open a new bug.
Is there any other factor, besides the kernel (other programs or script order) than might be causing the problem to still be present for Martin and is cleared up for most others that have the similar symptom? The problem no longer afflicts my HP laptop. I think that the bug should remain open for the reporter and further investigation into the source of the problem still needs to be pursued.
As others have reported, the newest FC3 kernel solves the problem for me too, took the acpi=ht off the options, rebooted, and then shutdown, and the shutdown worked fine.
Problem solved with latest kernel for me too. Info about my computer above.
Works for me now with a ECS k7vta3 MB, latest FC3 kernel. Outstanding.
still the same Problem on FC3 with the latest Kernel (kernel-2.6.10- 1.760_FC3.i686.rpm) should I open a new bug report ? I don't know if it's a problem with MSI BIOS. any hints ?
I'm experiencing the Power Off problem on a Shuttle system running kernel-2.6.10-1.770_FC3 kernel-utils-2.4-13.1.49_FC3 In my case I believe the problem appeared during an update of kernel-utils, I'll regress the package and post the results if I can make any progress.
Hi I'm having this problem with a newly built system. MSI 915P combo board Tried all latest kernels available through up2date aswell Interesting thing is that if there is no usb mouse plugged in then the system will power off correctly. However if the mouse is in then the system just pauses at the called ACPI_POWER_OFF statement
acpi=off works for me so far, but as I stated above that really isn't a fix for the problem really. Still same problem on all latest kernels for me, including the 2.6.11 kernel from FC4 test 1. I'm just still using 'acpi=off' on my grub.conf kernel line. (shrugs) nothing else has worked yet. not even apm=off so it must be something with acpi, must be still broken or something.
Fedora Core 2 has now reached end of life, and no further updates will be provided by Red Hat. The Fedora legacy project will be producing further kernel updates for security problems only. If this bug has not been fixed in the latest Fedora Core 2 update kernel, please try to reproduce it under Fedora Core 3, and reopen if necessary, changing the product version accordingly. Thank you.
Anyone still experiencing this bug with Fedora Core 3 or later should follow the progress on bug 155127.
could you please give a look to https://bugzilla.redhat.com/show_bug.cgi?id=840331