Latest working kernel version: no one Earliest failing kernel version: all I used Distribution: Now Fedora 10 but I tried many Hardware Environment: PackardBell V7900 lspci: 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express PCI Express Root Port (rev 03) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02) 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02) 01:00.0 VGA compatible controller: ATI Technologies Inc M56P [Radeon Mobility X1600] 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) 06:02.0 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02) 06:02.2 SD Host controller: O2 Micro, Inc. Integrated MMC/SD Controller (rev 01) 06:02.3 Mass storage controller: O2 Micro, Inc. Integrated MS/xD Controller (rev 01) 06:08.0 Ethernet controller: Intel Corporation PRO/100 VE Network Connection (rev 02) Software Environment: Fedora 10 & KDE Problem Description: My laptop doesn't shutdown correctly in many distros I've proven. The last message my laptop shows is "acpi power off called" In fedora 10 the last message is "System halted" And always stays there making me pushing down the power button for a while to get a successfull power off. I suffered always this issue in every distro with every kernel that I've proven Steps to reproduce: Just Shutdown
I don't suppose it works if you boot in APM mode with "acpi=off"? Please include the output of dmesg -s64000 and attach the output from acpidump.
Created attachment 19229 [details] acpidump acpidump About acpi=off I tried the following: acpi=off doesn't work the system doesn't start I need to put noapic With acpi=off and noapic don't shutdown correctly The last message when I shutdown is Halting System System halted and stays there I have to push down the power button And the messeage by default (with acpi) is Halting System Power Down and stays there I have to push down the power button too
Created attachment 19230 [details] dmesg -s64000 dmesg-s64000
Hi, Pablo Will you please confirm whether the box can be shutdown on windows XP? Will you please boot the system with ACPI disabled and attach the output of lspci -vxxx, dmesg? Will you please add the boot option of "maxcpus=1" and see whether the system can be shutdown correctly? Of course please attach the output of dmesg, lspci -vxxx. Thanks.
Created attachment 19248 [details] dmesg -s64000 boot options acpi=off noapic Doesn't shutdown correctly
Created attachment 19249 [details] dmesg -s64000 boot options maxcpus=1 The system works with only one core only but doesn't shutdown completely too
Created attachment 19250 [details] lspci -vxxx boot options acpi=off noapic
Created attachment 19251 [details] lspci -vxxx boot options maxcpus=1
Oh I forget to confirm that Windows XP shutdown ok
dmesg shows this system has additional, possibly related, EC problems: Linux version 2.6.27.5-117.fc10.i686 ... ACPI: EC: missing confirmations, switch off interrupt mode. ACPI Exception (evregion-0419): AE_TIME, Returned by Handler for [EmbeddedControl] [20080609] ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.BAT0._BST] (Node f7816b10), AE_TIME ACPI Exception (battery-0360): AE_TIME, Evaluating _BST [20080609] Are you able to reliably get consistent output to this command? grep . /proc/acpi/battery/BAT0/* Are you able to build a kernel.org kernel from source? If yes, please uncomment this line in drivers/acpi/ec.c /* #define DEBUG */ and report the last thing you see on a poweroff attempt.
ok, kernel 2.6.27.8 from kernel.org build from source with #define bug uncommented: Halting system... md: stopping all md devices. sd 0:0:0:0: [sda] Synchronizing SCSI cache sd 0:0:0:0: [sda] Stopping disk e100 0000:06:08.0: PCI INT A disabled ACPI: Preparing to enter system sleep state S5 Disabling non-boot CPUs --- Breaking affinity for irq 1 Breaking affinity for irq 9 Breaking affinity for irq 16 Breaking affinity for irq 20 CPU 1 is now offline SMP alternatives: switching tu UP code CPU1 is down Power down. acpi_power_off called I don't now, but is weird CPU 1 is now offline ... what about cpu0?
Created attachment 19284 [details] /proc/acpi/battery/BAT0/*
Hi, Pablo Will you please attach the output of acpidump? Thanks.
Created attachment 19287 [details] acpidump with ec.c #define debug uncommented kernel version 2.6.27.8 #define debug in ec.c
Created attachment 19288 [details] dmesg -s64000 with ec.c #define debug uncommented
Created attachment 19289 [details] lspci -vxxx with ec.c #define debug uncommented
Created attachment 19306 [details] [Debug patch]: Force to make ACPI/legacy mode switch regardless of current mode Hi, Pablo Will you please try the debug patch on the latest kernel and see whether the box can be shutdown? Thanks. Please not attach the output of lspci -vxxx.
Created attachment 19307 [details] try the attached tool to read/write some I/O port Will you please boot the system with ACPI disabled (by adding the boot option of "acpi=off")and do the following test? a. ./iow --addr 0xb2 --width 8 --value 0xA0 b. ./iow --addr 0x404 --width 16 --value 0x3C01 After doing the above test, please confirm whether the box can be shutdown. Thanks.
I tried the patch in the last kernel but it doesn't work either.. Haltin system... md: stopping all md devices. sd 0:0:0:0: [sda] Synchronizing SCSI cache sd 0:0:0:0: [sda] Stopping disk e100 0000:06:08.0: PCI INT A disabled ACPI: Preparing to enter system sleep state S5 Disabling non-boot CPUs ... Breaking affinity for irq 1 Breaking affinity for irq 9 Breaking affinity for irq 16 Breaking affinity for irq 20 CPU 1 is now offline SMP alternatives: switching to UP code CPU1 is down Power down. acpi_power_off called and stays there
Created attachment 19337 [details] acpidump with last kernel and patch
Created attachment 19338 [details] dmesg -s64000 with last kernel and patch
I tried with acpi=off and noapic the test a. ./iow --addr 0xb2 --width 8 --value 0xA0 With a. a0 is wrote en port b. ./iow --addr 0x404 --width 16 --value 0x3C01 With b. the box suddenly shutdown like if it hadn't have enough battery to stay power on
Hi, Pablo thanks for the test. From the test it seems that the poweroff still can't work after the debug patch is applied.(In the debug patch the system is switched to ACPI mode regardless of current mode). But from the info it seems that the system can be shutdown by writing 0x3C01 to PM1A control register after the system is booted with ACPI disabled and then switched to ACPI mode by writing ACPI_ENABLE to SMI command port. It is very interesting. In fact when the system is booted with ACPI enabled, the 0x3C01 will also be written into the PM1A control register. But unfortunately the system can't be shutdown. The difference is that no acpi driver is loaded while doing test in comment #22. Thanks.
Created attachment 19340 [details] The ACPI sci interrupt is disabled when entering S3/S5 Will you please try the debug patch and see whether the system can be shutdown correctly? In the debug patch the ACPI SCI interrupt will be disabled when entering S3/S5. Thanks.
it doesn't work either. I had to modify manually main.c in drivers/acpi/sleep cause your patch version and my main's version (kernel 2.6.27.8) I think are different cause it doesn't work (hunk #1 failed at16 main.c)
Created attachment 19347 [details] acpidump irq disabled patch
Created attachment 19348 [details] dmesg -s640000 irq disabled patch
Hi, Pablo thanks for the confirm. From the test it seems that the issue still exists after the patch in comment #24 is applied. But in the test of comment #22 the system is shutdown after writing 0x3C01 to PM1A control register when the system is booted with ACPI disabled. Thanks.
Created attachment 19421 [details] ACPI is initialized after scanning pci devices Will you please try the debug patch on the latest kernel(2.6.28-rc8) and see whether the system can be shutdown? In the debug patch the ACPI is initialized after scanning pci devices. Thanks.
Created attachment 19435 [details] acpidump acpi after scanning patch kernel 2.6.28-rc8 Doesn't shutdown
Created attachment 19436 [details] dmesg -s64000 acpi scanning patch
Hi, Pablo Thanks for the test. From the test we know that it won't be affected by the initial order between ACPI and PCI. Now I have no idea about how to get the root cause of this bug. In fact we have another similar bug:8549. The system can't be shutdown with ACPI. But it can be shutdown by writting S5 SLP_TYPE to PM1A control register when the system is booted without ACPI. Thanks.
Hi, Pablo We have another similar bug(8549) on kernel bugzilla. And I have no idea about how to get the root cause of this bug. And this bug will be marked as the duplicate of bug8549. Thanks. *** This bug has been marked as a duplicate of bug 8549 ***
ok I will follow the bug on the other box. Thanks.
Hi, Pablo thanks for the understanding. Do you have an opportunity to try the two debug patches in http://bugzilla.kernel.org/show_bug.cgi?id=8549#C73,74 and see whether the system can be shutdown? If the two debug patches are tried, you needn't use the command of "poweroff" or "shutdown". It is done automatically in the boot phase. Thanks.