Bug 2593 - System won't power off with ACPI - Asus A7S333
Summary: System won't power off with ACPI - Asus A7S333
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Off (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Len Brown
Depends on:
Reported: 2004-04-26 03:00 UTC by Anssi Saari
Modified: 2004-11-04 18:33 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6 (all), 2.4 (all)
Regression: ---
Bisected commit-id:

dmesg output (124 bytes, text/html)
2004-04-26 03:03 UTC, Anssi Saari
dmidecode output (146 bytes, text/html)
2004-04-26 03:36 UTC, Anssi Saari
acpidmp output (142 bytes, text/html)
2004-04-26 03:38 UTC, Anssi Saari
lspci -vv output (144 bytes, text/html)
2004-04-26 03:39 UTC, Anssi Saari
/proc/interrupts (144 bytes, text/html)
2004-04-26 03:41 UTC, Anssi Saari
disable cpu setting in non-SMP case (938 bytes, patch)
2004-10-20 06:55 UTC, Alexey Starikovskiy
Details | Diff

Description Anssi Saari 2004-04-26 03:00:18 UTC
Distribution: Debian
Hardware Environment: Asus A7S333 motherboard with SiS735 chipset
Problem Description: System won't power off with ACPI. No error messages, but 
doesn't power off either.
Comment 1 Anssi Saari 2004-04-26 03:03:46 UTC
Created attachment 2713 [details]
dmesg output
Comment 2 Anssi Saari 2004-04-26 03:36:31 UTC
Created attachment 2714 [details]
dmidecode output
Comment 3 Anssi Saari 2004-04-26 03:38:09 UTC
Created attachment 2715 [details]
acpidmp output
Comment 4 Anssi Saari 2004-04-26 03:39:16 UTC
Created attachment 2716 [details]
lspci -vv output
Comment 5 Anssi Saari 2004-04-26 03:41:59 UTC
Created attachment 2717 [details]
Comment 6 Anssi Saari 2004-04-26 03:46:32 UTC
Chipset is actually SiS745, not SiS735.
Comment 7 Nicolas Brouard 2004-05-07 09:15:28 UTC
I got the same problem with a Sony Z1 and someone told me to add nolapic in
lilo/grub and it worked.
Comment 8 Nic Doye 2004-08-19 07:45:09 UTC
I have the same motherboard at home.

I _believe_ that power worked properly  under Mandrake 10.0, but under Fedora
Core 2 it's hosed. I've set acpi=off, but I'll try the noapic nolapic options
Comment 9 Nic Doye 2004-08-19 15:12:27 UTC
Nicolas Brouard's suggestion works fine on this Mobo.

Exact working config (ripped from /etc/grub.conf)

title Fedora Core (2.6.8-1.520)
        root (hd0,4)
        kernel /vmlinuz-2.6.8-1.520 ro root=LABEL=/ rhgb quiet idebus=66 noacpi
noapic nolapic acpi=off
        initrd /initrd-2.6.8-1.520.img

Kernel comes from http://people.redhat.com/~arjanv/2.6/

I think this bug can be closed.
Comment 10 Anssi Saari 2004-08-19 23:07:49 UTC
Nic Doye, you turned ACPI off in your "fix". The bug I reported is specifically 
that ACPI doesn't turn power off. I'm not looking for workarounds, I just 
reported a bug I'd like fixed at some point. "nolapic" isn't it either.
Comment 11 Nic Doye 2004-08-20 01:50:55 UTC
Please accept my apologies for being a complete idiot.

I can't recall how Mandrake 10.0 "worked" on this motherboard: whether ACPI was
disabled or there's a patch in their kernel. I'd suggest a cursory glance at
their  kernel source.

Reply to bugs in haste (without looking at the source/docs), repent and look
stupid forever. Please accept my apologies once more.
Comment 12 Marco Martin 2004-10-17 10:58:22 UTC
I think this bug was introdoced with the fix of the bug 1141, i tried to comment 
out the line
	/* Some SMP machines only can poweroff in boot CPU */
	set_cpus_allowed(current, cpumask_of_cpu(0));
in /drivers/acpi/sleep/poweroff.c and now my a7s333 shuts down properly.

what about executing that line only if the system is tryly an SMP?
Comment 13 Alexey Starikovskiy 2004-10-20 05:13:38 UTC
Marco, does your system run SMP kernel on UP box?
set_cpus_allowed() should be NOP in non-SMP kernel...
Could you please attach your .config?
Comment 14 Alexey Starikovskiy 2004-10-20 06:55:44 UTC
Created attachment 3865 [details]
disable cpu setting in non-SMP case

Could you please check if following patch does the job?
Comment 15 Len Brown 2004-10-26 11:04:47 UTC
Anssi, Nic, Marco,
Please confirm that you are running a kernel with CONFIG_SMP=y,
and that the problem goes away when CONFIG_SMP=n.

Looking at the CONFIG_SMP kernel:

[root@d600 root]# gdb /boot/vmlinux-26-latest-dev /proc/kcore
(gdb) x/20ai acpi_power_off
0xc0242304 <acpi_power_off>:    push   $0xc041ca64
0xc0242309 <acpi_power_off+5>:  push   $0xc0449470
0xc024230e <acpi_power_off+10>: call   0xc0121eb0 <printk>
0xc0242313 <acpi_power_off+15>: pop    %eax
0xc0242314 <acpi_power_off+16>: pop    %edx
0xc0242315 <acpi_power_off+17>: mov    $0xfffff000,%eax
0xc024231a <acpi_power_off+22>: push   $0x1
0xc024231c <acpi_power_off+24>: and    %esp,%eax
0xc024231e <acpi_power_off+26>: pushl  (%eax)
0xc0242320 <acpi_power_off+28>: call   0xc011ec90 <set_cpus_allowed>
0xc0242325 <acpi_power_off+33>: push   $0x5
0xc0242327 <acpi_power_off+35>: call   0xc022f86b <acpi_enter_sleep_state_prep>
0xc024232c <acpi_power_off+40>: cli
0xc024232d <acpi_power_off+41>: push   $0x5
0xc024232f <acpi_power_off+43>: call   0xc022f9fb <acpi_enter_sleep_state>
0xc0242334 <acpi_power_off+48>: add    $0x10,%esp
0xc0242337 <acpi_power_off+51>: ret

Looking at the CONFIG_SMP=n kernel:

(gdb) x/20ai acpi_power_off
0xc022f8f8 <acpi_power_off>:    push   $0xc03f9324
0xc022f8fd <acpi_power_off+5>:  push   $0xc042546c
0xc022f902 <acpi_power_off+10>: call   0xc011d6e0 <printk>
0xc022f907 <acpi_power_off+15>: pop    %ecx
0xc022f908 <acpi_power_off+16>: pop    %eax
0xc022f909 <acpi_power_off+17>: push   $0x5
0xc022f90b <acpi_power_off+19>: call   0xc021cc8b <acpi_enter_sleep_state_prep>
0xc022f910 <acpi_power_off+24>: cli
0xc022f911 <acpi_power_off+25>: push   $0x5
0xc022f913 <acpi_power_off+27>: call   0xc021ce1b <acpi_enter_sleep_state>
0xc022f918 <acpi_power_off+32>: pop    %eax
0xc022f919 <acpi_power_off+33>: pop    %edx
0xc022f91a <acpi_power_off+34>: ret

Shows that the inline correctly removes the call to set_cpus_allowed()
in the CONFIG_SMP=n case -- so putting an #ifdef around
this call should have no effect, and commenting out this
line on a CONFIG_SMP=n kernel should also have no effect.
Comment 16 Anssi Saari 2004-10-26 11:43:14 UTC
I unfortunately don't have the motherboard running any more. I reported this six
months ago today after all... But I'm almost certain I didn't run SMP kernels on
the system back then. I did have local APIC and IO-APIC enabled, though.
Comment 17 Marco Martin 2004-10-26 12:51:40 UTC
Sorry, it was my fault. 
after some more experiments i found that it doesn't depend on that.
Now i'm trying to recreate the exact kernel configuration that made the acpi 
Comment 18 Len Brown 2004-10-26 21:23:24 UTC
thanks for the quick reqply.
Please confirm that a 2.6.9 (or newer) ACPI kernel still fails to poweroff on 
the Asus A7S333.  I see from comment #1 that this board has an IOAPIC -- 
so "nolapic" would be a bogus workaround, but for debugging, please make sure 
that it has no effect on the failure.
Comment 19 Marco Martin 2004-10-27 12:03:07 UTC
now i have a 2.6.7, i'm downloading the 2.6.9, i will try more accurately with 
it. One thing i noticed today is that it doesn't shut down properly when the 
sleep states support is enabled in kernel config and shuts down properly if 
sleep states support is disabled. i don't know if it will help
Comment 20 Marco Martin 2004-10-29 12:12:44 UTC
with 2.6.9 everithing seems work, either with the sleep states enabled or not.
I think it is... fixed?
Comment 21 Len Brown 2004-11-04 18:33:46 UTC
probably a dupe of 2109
open a new one if you see problems going forward.


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