Bug 6655 - S3 resume breaks reboot - Asus M6A notebook
Summary: S3 resume breaks reboot - Asus M6A notebook
Alias: None
Product: Power Management
Classification: Unclassified
Component: Hibernation/Suspend (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Rafael J. Wysocki
: 4020 5396 8951 (view as bug list)
Depends on:
Blocks: 7216
  Show dependency tree
Reported: 2006-06-06 02:10 UTC by Lukas Hejtmanek
Modified: 2008-12-03 18:47 UTC (History)
9 users (show)

See Also:
Kernel Version: 2.6.17-rc5
Regression: ---
Bisected commit-id:

debug patch (3.03 KB, patch)
2006-06-12 00:01 UTC, Luming Yu
Details | Diff
dmesg (12.27 KB, text/plain)
2006-06-13 00:30 UTC, Lukas Hejtmanek
acpidump (172.17 KB, text/plain)
2006-06-13 00:49 UTC, Lukas Hejtmanek
disable acpi before reboot (647 bytes, patch)
2006-06-20 23:07 UTC, Luming Yu
Details | Diff
Output of lspci -v from affected Intel-based desktop (3.84 KB, text/plain)
2007-06-01 10:38 UTC, Rafael J. Wysocki
patch to force the triple fault reset on i386 (721 bytes, patch)
2007-06-02 07:45 UTC, Rafael J. Wysocki
Details | Diff
Working patch (2.10 KB, patch)
2007-06-02 09:08 UTC, Rafael J. Wysocki
Details | Diff

Description Lukas Hejtmanek 2006-06-06 02:10:59 UTC
Most recent kernel where this bug did not occur: n/a
Distribution: Debian/sid
Hardware Environment: Asus M6A notebook
Software Environment:
Problem Description: After S3 STR reboot does not work, I've tried reboot=w,h
and reboot=c,b, no luck. System shows message about restarting system. Caps lock
and num lock LEDs flash, but it does not reboot.

Steps to reproduce: Do S3 susped, try to reboot.
Comment 1 Len Brown 2006-06-06 14:59:35 UTC
Did this work with a previous release, or is 2.6.17-rc5 the only tested?

After STR, does a regular "init 0" work properly?
Comment 2 Lukas Hejtmanek 2006-06-06 15:05:44 UTC
> Did this work with a previous release, or is 2.6.17-rc5 the only tested?

I do not know any kernel that works. (beginning arount 2.6.13).

> After STR, does a regular "init 0" work properly?

I will try it and let you know. (What does exactly mean 'work properly' in this
Comment 3 Len Brown 2006-06-06 15:36:58 UTC
> What does exactly mean 'work properly' in this case?

In ACPI mode, "# init 0" should do a "soft power-off",
ie a graceful shutdown and poweroff.  This path shares
a bunch of code with the reboot case.

Comment 4 Lukas Hejtmanek 2006-06-07 02:16:32 UTC
init 0 works ok. It says: Will now halt. And then it halts after STR.

init 6 says:
Will now restart
Restarting system

and nothing more. Looks like it hangs in BIOS (LEDs flash like booting).
Comment 5 Luming Yu 2006-06-07 07:29:50 UTC
Does MS windows work? If this is BIOS problem, it would affect windows too.
Comment 6 Lukas Hejtmanek 2006-06-07 12:38:12 UTC
> Does MS windows work? If this is BIOS problem, it would affect windows too.

In Windows, it is ok.

Moreover, in Windows, Fn+sleep button wakes up from STR. In Linux, it does not
(only the power button does resume).
Comment 7 Luming Yu 2006-06-11 21:40:06 UTC
Please check if RESET_REG_SUP is set in FADT.
If yes, it would be worthy to test ACPI FADT reset register works or NOT.
Comment 8 Luming Yu 2006-06-12 00:01:00 UTC
Created attachment 8288 [details]
debug patch

Use ACPI FADT reset register.
The original patch is at
Comment 9 Luming Yu 2006-06-12 00:04:17 UTC
*** Bug 5396 has been marked as a duplicate of this bug. ***
Comment 10 Luming Yu 2006-06-12 00:10:35 UTC
*** Bug 4020 has been marked as a duplicate of this bug. ***
Comment 11 Lukas Hejtmanek 2006-06-12 05:01:20 UTC
> Please check if RESET_REG_SUP is set in FADT.
> If yes, it would be worthy to test ACPI FADT reset register works or NOT.

How do I do this?
Comment 12 Luming Yu 2006-06-12 05:53:02 UTC
Pleae try the attached patch, boot kernel, 
search "machine_reset = acpi_machine_reset" in dmesg 
Comment 13 Lukas Hejtmanek 2006-06-12 08:55:00 UTC
Patch applied:
anubis:# dmesg | grep machine_reset
Comment 14 Luming Yu 2006-06-12 18:01:48 UTC
I have ASUS A6B, that patch fixed the problem.

Re: grep "macine_reset" get nothing:
Please get full dmesg, and post it here.

Anyway, please test the patch.

Comment 15 Lukas Hejtmanek 2006-06-13 00:30:33 UTC
Created attachment 8292 [details]
Comment 16 Lukas Hejtmanek 2006-06-13 00:31:49 UTC
I've tried to reboot with the patch - no luck, still not working.
Comment 17 Luming Yu 2006-06-13 00:39:33 UTC
Please post acpidump output too.
Comment 18 Lukas Hejtmanek 2006-06-13 00:49:44 UTC
Created attachment 8293 [details]
Comment 19 Luming Yu 2006-06-13 01:23:28 UTC
The FADT shows NO reset register support.

Then, could you verify you are using the latest BIOS.
Comment 20 Lukas Hejtmanek 2006-06-13 01:44:44 UTC
I'm using the latest available BIOS. And in windows, it works.
Comment 21 Luming Yu 2006-06-13 02:15:27 UTC
Ok, could you remove unnecessary ACPI modules, and re-test.

Comment 22 Lukas Hejtmanek 2006-06-13 02:37:44 UTC
I left only:

which is mimimum acording to menuconfig. Without ACPI STR does not work.
Comment 23 Luming Yu 2006-06-20 23:07:06 UTC
Created attachment 8358 [details]
disable acpi before reboot

Please try the attached patch. I tested this on my asus A6BA, it fix the
S3 reboot hang issue. I guess it should fix your problem , even if your box
don't have FADT reset register.
Comment 24 Lukas Hejtmanek 2006-06-21 11:22:28 UTC
Looks like it's OK. At least initial sequence S3, reboot. Thanks. Will you
commint this patch into mainline?
Comment 25 Luming Yu 2006-06-22 09:24:41 UTC
I guess it will.
Signed-off-by: Luming Yu <luming.yu@intel.com>
fot patch at comment# 23

patch at comment#23 needs go into -mm tree for wider testing.
Comment 26 Andrea Vettorello 2006-07-15 04:22:28 UTC
Works for me, i've tested the patch in comment# 23 and it fixes the reboot
problem i reported in Bug 4020.

Comment 27 Zhang Rui 2007-01-17 23:40:33 UTC
I can reproduce the problem on a Lenovo 945G platform.
Luming's patch in comment#23 fix the problem.
Len, will this hit the mainline?
Comment 28 Nicolo' Chieffo 2007-01-19 07:00:38 UTC
Hello! I have an asus M6Ne laptop and I'm affected by the exactly same bug. I
did apply the last patch (comment #23) but the problem remains. Only one thing
is better: now to switch down the machine I don't have to keep the power button
for 5 seconds, but just one hit is enough! What should I try?

I have this line about FADT in my normal ubuntu kernel

ACPI: FADT (v001 A M I  OEMFACP  0x03000528 MSFT 0x00000097) @ 0x1ff40200

I will try the first patch now
Comment 29 Nicolo' Chieffo 2007-01-19 07:13:13 UTC
The patch caused a compile error: I'm using 2.6.20.
In fact there is no "type" caled FADT_DESCRIPTOR in that file...

drivers/acpi/bus.c: In function 
Comment 30 Nicolo' Chieffo 2007-01-19 14:18:42 UTC
for linux-2.6.20 I needed to change the patch from

FADT_DESCRIPTOR *f = &acpi_fadt;


struct fadt_descriptor *f = &acpi_fadt;
Comment 31 Nicolo' Chieffo 2007-01-19 15:39:29 UTC
The first patch did not help at all.
Comment 32 Len Brown 2007-03-08 23:15:12 UTC
re: the patch in comment #8 adding acpi_machine_reset()
it is missing credit to the original author, and has removed
the x86_64 support, so it can not be applied.

re: the patch in comment #23 exiting acpi mode on reset
it is also i386 specific, will not build for CONFIG_ACPI=n
and I don't understand why it works.
Comment 33 Rafael J. Wysocki 2007-05-20 15:15:49 UTC
I'm able to reproduce the problem on Asus L5D with 2.6.22-rc2/x86-64, 100% of 
the time (it only suspends in the init=/bin/bash "mode", but that's 

I have debugged it a little and found that the box hangs hard after the first 
outb(0xfe,0x64), arch/x86_64/kernel/reboot.c:129 .  It sometimes reaches the 
second read (ie. kb_wait(), arch/x86_64/kernel/reboot.c:127), but not always.

Tomorrow I'll try the patch from Comment #8.
Comment 34 Rafael J. Wysocki 2007-05-31 10:04:09 UTC
The approach from Comment #8 is not practical, because the machine's FADT
revision is 1.  Moreover, none of the machines I have checked (some of them
pretty modern) support the Reset Register.

The hack from Comment #23 apparently doesn't work on this box.

I'm going to check if the triple fault reset works (I suspect it will).

It seems to me that on the affected machines the keyboard is handled by the
embedded controller using the "traditional" keyboard ports, so the write in
arch/x86_64/kernel/reboot.c:129 actually goes to the EC which mishandles it.
Comment 35 Rafael J. Wysocki 2007-06-01 10:38:48 UTC
Created attachment 11638 [details]
Output of lspci -v from affected Intel-based desktop

I can reproduce this problem (100% of the time) on yet another machine, which
is a Celeron-based desktop with an Intel chipset and GeForce MX 400 (the output
of 'lspci -v' from this box is attached).

Apart from this, 's2ram --force --vbe_post --vbe_mode' works just fine on this
box  (except for a glitch cuased by ehci_hcd that makes it resume right after
the suspend, but this is a different issue).
Comment 36 Rafael J. Wysocki 2007-06-02 05:45:54 UTC
On the machine from Comment #35, the triple-fault reset doesn't work after a
resume from RAM.
Comment 37 Mikhail Gusarov 2007-06-02 06:03:06 UTC
>the triple-fault reset doesn't work after a resume from RAM.

Could you post a patch? I'd like to see whether it works for M6N.
Comment 38 Rafael J. Wysocki 2007-06-02 07:45:12 UTC
Created attachment 11640 [details]
patch to force the triple fault reset on i386
Comment 39 Rafael J. Wysocki 2007-06-02 09:08:48 UTC
Created attachment 11642 [details]
Working patch

The attached patch, based on the patch from Comment #23, helps the machine from
Comment #35 reboot after a resume from RAM.

Of course, _why_ it works is a different issue. ;-)

To double check, I'll see if the x86_64 version will help on Asus L5D.
Comment 40 Mikhail Gusarov 2007-06-02 11:05:42 UTC
Patches from #38 or #39 do not change anything on m6b00n :(
Comment 41 Rafael J. Wysocki 2007-06-02 16:04:00 UTC
As expected, the x86_64 version of the patch from Comment #39 doesn't work on
Asus L5D.
Comment 42 Stefan Seyfried 2007-06-05 10:16:10 UTC
JFTR: my Toughbook CF-51, which had problems in the past rebooting after S3 
now reboots fine with 2.6.22-rc3-git2
Comment 43 Mikhail Gusarov 2007-06-05 20:21:17 UTC
Due to Comment #42 tried 2.6.22-rc4 on M6B00N: still does not reboot after S3 
Comment 44 Fabien Wernli 2007-06-17 05:35:04 UTC
Same here using 2.6.21 on the box identified by:

    sys_vendor   = "MSI."
    sys_product  = "MS-7207PV"
    sys_version  = "100"
    bios_version = "080012 "

however acpi off only stops working after suspend if I use vga=792 or other. If I use vga=normal on the kernel cmdline, it works!
Comment 45 Rafael J. Wysocki 2007-06-17 14:15:31 UTC
I guess you mean restart?  ACPI off works on all of my test boxes after the resume, but the restart doesn't work on some of them (booting with vga=normal doesn't change anything).
Comment 46 Rafael J. Wysocki 2007-10-02 04:38:57 UTC
*** Bug 8951 has been marked as a duplicate of this bug. ***
Comment 47 Steve Tyler 2008-03-09 14:07:14 UTC
The "disable acpi before reboot" patch (#23 From Luming Yu) works on an ASUS Z91E notebook (also called the A3E) with BIOS version 204. The system restarts as expected after a suspend/resume.

The patch was applied to a custom configuration built from Fedora 8 

The system does not restart when using these stock Fedora kernels:
Comment 48 ykzhao 2008-09-23 01:55:13 UTC
    From the acpidump it seems that there exists the definition of RESET_REG although the RESET_REG is not supported.(The RESET_REG bit of FADT is zero).
    > RESET_REG 0xCF9
    > RESET_VALUE : 0x06
    Will you please attach the output of dmidecode?
Comment 49 ykzhao 2008-11-16 22:58:17 UTC
Hi, Steve
    Will you please try the latest kernel and see whether the problem still exists?
Comment 50 Steve Tyler 2008-12-03 14:50:57 UTC
(In reply to comment #49)
> Hi, Steve
>     Will you please try the latest kernel and see whether the problem still
> exists?
>     Thanks.

Suspending, resuming, and restarting on my ASUS Z91E works with
Fedora 9 kernel dated Thu Nov 13 20:52:14 EST 2008.

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