Bug 3691 - PM1_STATUS bits not preserved - S3 resume becomes cold boot - ECS G320 laptop
Summary: PM1_STATUS bits not preserved - S3 resume becomes cold boot - ECS G320 laptop
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Sleep-Wake (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Shaohua
: 2347 (view as bug list)
Depends on:
Reported: 2004-11-03 15:16 UTC by Matthew Garrett
Modified: 2007-02-05 20:07 UTC (History)
8 users (show)

See Also:
Kernel Version: 2.6.9
Regression: ---
Bisected commit-id:

acpidmp output from EiSystems 3001 (58.30 KB, application/octet-stream)
2004-11-12 03:59 UTC, Matthew Garrett
acpidmp output (83.38 KB, text/plain)
2004-11-18 10:42 UTC, Andrew J. Montalenti
lspci output (1.22 KB, text/plain)
2004-11-18 10:43 UTC, Andrew J. Montalenti
Test patch (491 bytes, patch)
2004-12-12 19:17 UTC, Shaohua
Details | Diff
acpidmp from AV3250HX-01 kernel (83.38 KB, text/plain)
2005-03-14 16:56 UTC, Jason Dagit
dmesg from AV3250HX-01 kernel (10.29 KB, text/plain)
2005-03-14 16:56 UTC, Jason Dagit
dmidecode from AV3250HX-01 kernel (7.21 KB, text/plain)
2005-03-14 16:57 UTC, Jason Dagit
DSDT from AV3250HX-01 kernel (17.73 KB, application/octet-stream)
2005-03-14 16:57 UTC, Jason Dagit
/proc/interrupts from AV3250HX-01 kernel (554 bytes, text/plain)
2005-03-14 16:58 UTC, Jason Dagit
lspci -vv from AV3250HX-01 kernel (9.32 KB, text/plain)
2005-03-14 16:59 UTC, Jason Dagit
debug patch (1.83 KB, patch)
2005-09-20 21:57 UTC, Shaohua
Details | Diff
Attempt to fix up abnormal power-off flag at boot (1.21 KB, patch)
2006-06-18 18:36 UTC, Matthew Garrett
Details | Diff

Description Matthew Garrett 2004-11-03 15:16:04 UTC
S1 works without problems (except for the screen not being blanked). S3 appears
to suspend correctly on a kernel with no modules loaded. Pressing the power
button results in the machine behaving as if power is being applied from scratch
- no wakeup code appears to be run.

I've applied the patch that ensures that the wakeup vector contains the physical
address of the wakeup code, and also the patch to ensure that the GDT is copied
to low memory. These do not appear to make any difference. Adding code to send
output to the parallel port at the start of the wakeup code does not result in
output. Adding an infinite loop at the start of the wakeup code doesn't appear
to change behaviour.
Comment 1 Shaohua 2004-11-12 01:30:39 UTC
>Adding an infinite loop at the start of the wakeup code doesn't appear
>to change behaviour.
So this means the system never get a correct wakeup address, right? I'd like 
to check FADT table, please attach your acpidmp
Does this system have latest BIOS and work with WinXP?
Comment 2 Shaohua 2004-11-12 01:45:42 UTC
Maybe a blind guess, but how about apply below patch:
--- a/drivers/acpi/tables/tbconvrt.c.orig	2004-11-12 17:34:52.386045104 
+++ b/drivers/acpi/tables/tbconvrt.c	2004-11-12 17:35:21.091681184 +0800
@@ -522,8 +522,7 @@ acpi_tb_build_common_facs (
 	acpi_gbl_common_fACS.global_lock = &(acpi_gbl_FACS->global_lock);
 	if ((acpi_gbl_RSDP->revision < 2) ||
-		(acpi_gbl_FACS->length < 32) ||
-		(!(acpi_gbl_FACS->xfirmware_waking_vector))) {
+		(acpi_gbl_FACS->length < 32)) {
 		/* ACPI 1.0 FACS or short table or optional X_ field is zero */
 		acpi_gbl_common_fACS.firmware_waking_vector = ACPI_CAST_PTR 
(u64, &(acpi_gbl_FACS->firmware_waking_vector));

And please print some info in routine 'acpi_set_firmware_waking_vector', I'd 
like know which branch is taken in your system.
Comment 3 Matthew Garrett 2004-11-12 03:59:10 UTC
Created attachment 4020 [details]
acpidmp output from EiSystems 3001
Comment 4 Matthew Garrett 2004-11-12 04:00:19 UTC
I've attached the acpi tables (EiSystems is the brand name, the hardware is made
by ECS)
Comment 5 Matthew Garrett 2004-11-12 04:26:52 UTC
The patch in comment 2 doesn't appear to alter anything. Checking with
acpi_set_firmware_wakeup_vector, the code goes through the if statement and not
the else statement (ie, acpi_gbl_common_fACS.vector_width is equal to 32)
Comment 6 Shaohua 2004-11-14 22:32:32 UTC
Could you please tell me what's chipset type (MCH, ICH) of the system? I 
noticed the BIOS do some PCI config write in MCH. And please try
acpi_os_name=Microsoft Windows NT   or
acpi_os_name=Microsoft Windows       or
acpi_os_name=Microsoft WindowsME: Millennium Edition
The write to MCH diffs from varient os name.
Comment 7 Matthew Garrett 2004-11-15 06:33:44 UTC
Changing the OS name appears to make no difference. It's a VIA-based machine -
lspci gives:

0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8623 [Apollo CLE266]
0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP]
Comment 8 Matthew Garrett 2004-11-15 17:21:54 UTC
Sorry, I forgot to mention - Windows XP appears to work correctly on this
hardware, but FreeBSD fails in the same way as Linux.
Comment 9 Andrew J. Montalenti 2004-11-18 10:42:29 UTC
Created attachment 4079 [details]
acpidmp output
Comment 10 Andrew J. Montalenti 2004-11-18 10:43:24 UTC
Created attachment 4080 [details]
lspci output
Comment 11 Andrew J. Montalenti 2004-11-18 10:44:45 UTC
I wanted to confirm this bug for an Averatec 3225 laptop, also on VIA hardware.
 I can resume S3 (even with modules loaded) and the screen blanks and the power
indicator starts to blink (which, when doing a Windows sleep, indicates the
machine has really been put into sleep mode).  However, while under Windows
hitting any key or hitting the power button results in a resume, under Linux
keys have no effect and the power button simply reboots the machine.

I have also applied the patch that ensures the wakup vector contains a physical
address, but it doesn't help.  Considering both the original poster and I have
VIA motherboards in our machines, it's very possible a fix to our problems will
fix a whole class of S3-resume-related problems.  I'd be perfectly willing to do
whatever debug work kernel developers think is necessary to squash this bug.

Attached are lspci and acpidmp output.
Comment 12 Shaohua 2004-11-22 22:43:08 UTC
Hi, andrew. The problem of the issue is we actually can't debug it. In 
matthieu's system, resume code never is invoked. Possibly a VIA motherboard is 
required to test it. I'll try if I can get one.
Comment 13 Shaohua 2004-12-12 19:17:03 UTC
Created attachment 4259 [details]
Test patch

I wonder if the BIOS tells wrong sleep type. In most systems, the sleep type
returned in _S3 is the same. Just a guess, please try. Thanks.
Comment 14 Jim Paris 2004-12-12 20:09:16 UTC
I made the _S3 types the same on my friend's laptop by changing the DSDT; no
change.  He also has an Averatec 3225 like comment #11.

(In #11 presumably he meant "I can suspend S3", not "I can resume S3")?
Comment 15 Shaohua 2004-12-16 01:17:27 UTC
Could you please try the workaround in bug 3909?
My HP nx5000 S3 failure looks like yours. Thanks.
Comment 16 Matthew Garrett 2004-12-16 05:16:57 UTC
I'm afraid not - the system still immediately reboots on pressing the power button.
Comment 17 Len Brown 2005-01-03 20:30:35 UTC
same with 2.6.10?
Comment 18 Matthew Garrett 2005-01-08 11:12:15 UTC
Yup, same with 2.6.10 (plus the immediate post-2.6.10 ACPI patch)
Comment 19 Matthew Garrett 2005-01-09 07:04:12 UTC
Upgrading to the latest BIOS hasn't altered this behaviour.
Comment 20 Shaohua 2005-01-26 17:27:57 UTC
Did you try the patch in
Comment 21 Nikolay Shtinkov 2005-01-28 06:30:30 UTC
The patch didn't change anything on my Averatec 3225 laptop, kernel 2.6.11-rc2.
Comment 22 Matthew Garrett 2005-02-23 06:49:01 UTC
No, the patch mentioned in comment 20 has no effect on the system.
Comment 23 Jason Dagit 2005-03-14 16:31:04 UTC
I have an Averatec laptop (AV3250HX-01) that also has the symptomps described. 
This is with 2.6.10 and  I've found that the powering off behavior
isn't really related to the power button.  My system can also wake on USB.  When
I plugin a USB device the system reboots.

echo EHCI > /proc/acpi/wakeup
echo mem > /sys/power/state
Now plugin a usb mouse and the system reboots.

This functionality works fine in windows xp home edition that came with the laptop.

I have tried setting acpi_os_name="Microsoft Windows NT" but the behavior did
not change.

Comment 24 Jason Dagit 2005-03-14 16:56:12 UTC
Created attachment 4715 [details]
acpidmp from AV3250HX-01 kernel
Comment 25 Jason Dagit 2005-03-14 16:56:47 UTC
Created attachment 4716 [details]
dmesg from AV3250HX-01 kernel
Comment 26 Jason Dagit 2005-03-14 16:57:17 UTC
Created attachment 4717 [details]
dmidecode from AV3250HX-01 kernel
Comment 27 Jason Dagit 2005-03-14 16:57:44 UTC
Created attachment 4718 [details]
DSDT from AV3250HX-01 kernel
Comment 28 Jason Dagit 2005-03-14 16:58:37 UTC
Created attachment 4719 [details]
/proc/interrupts from AV3250HX-01 kernel
Comment 29 Jason Dagit 2005-03-14 16:59:01 UTC
Created attachment 4720 [details]
lspci -vv from AV3250HX-01 kernel
Comment 30 Jason Dagit 2005-03-22 00:19:08 UTC
I found this bug today:

Could others experiencing this bug try commenting the lines described in comment
#3 on that bug?  It worked for me, the laptop does a suspend/resume.  The only
problem being that I haven't worked out how to make the video resume (just a
blank screen).  But I know the laptop is working because I can type "find /" and
I get hard drive activity and the capslock key works.
Comment 31 Shaohua 2005-03-22 00:24:47 UTC
Do you means delete the 'pushl 0; popfl' ?
how about change them to 'pushw 0; popfw'?
Comment 32 Jason Dagit 2005-03-22 00:37:22 UTC
Changing them to pushw and popw is not enough.  I have to actually delete the
Comment 33 Jason Dagit 2005-03-22 02:53:24 UTC
Something strange is definitely happening in wakeup.S.  The version without
pushl/popl worked for about 20 reboots while I tested options and tried to get
the video to resume.  But then suddenly it has stopped working and the machine
now reboots instead of resuming.  I tried booting into WinXP and then booting
into my modified kernel.  When I do that the machine crashes right after it
resumes.  I don't have video so I don't know if there is an oops or other useful

bug 3568 mentions using dead-loops and beeps to pinpoint the failure.  Does
anyone know the code for doing that?  I'd like to apply that some strategy on my
machine if I can.

Why would the machine reboot on pushl $0?  I've never done any serious asm
programming so I don't know what is going on.

If there is anything I can do that would be helpful in figuring this out, please
let me know.  I am eager to resolve this bug.

Comment 34 Alberto Piai 2005-03-23 03:22:47 UTC
I added this at the beginning of wakeup.S (right after the includes)

#define BEEP \
        inb     $97, %al;       \
        outb    %al, $0x80;     \
        movb    $3, %al;        \
        outb    %al, $97;       \
        outb    %al, $0x80;     \
        movb    $-74, %al;      \
        outb    %al, $67;       \
        outb    %al, $0x80;     \
        movb    $-119, %al;     \
        outb    %al, $66;       \
        outb    %al, $0x80;     \
        movb    $15, %al;       \
        outb    %al, $66;

then moved a BEEP statement around to narrow down to the line causing the problem.
after deleting the pushl $0 line, my laptop goes trough the entire wakeup.S,
then crashes somewhere out of it (after the Back to C debug output)...

it looks like there are 2 kind of bugs out there:
1.wakeup code is never executed
2.the kernel gains control but reboot is triggered by the pushl $0
is it right?
Comment 35 Jason Dagit 2005-03-23 13:31:16 UTC
On my system the code to do the beeping does not work.  (My system could very
well lack a PC speaker).  But I wiped out my kernel and went back to the stock
2.6.12-rc1 source with my current config and I was just able to suspend/resume
after commenting out the pushl/popl.

I'll be posting more information in bug 3586 as it seems more relevant there.
Comment 36 Shaohua 2005-03-23 23:24:26 UTC
Please check if below change fixes the issue:
-        mov     $(wakeup_stack - wakeup_code), %sp
+        movl     $(wakeup_stack - wakeup_code), %esp
I suspect the high bits of esp isn't cleared.
Comment 37 Shaohua 2005-08-10 22:30:26 UTC
Matthew, does s3 work without any driver loaded in the system?
For convenience, you can access bug 5037 to get a initramfs.
Comment 38 Shaohua 2005-09-20 21:57:01 UTC
Created attachment 6064 [details]
debug patch

I wonder if it helps if we set the BIOS reset entry to wakeup code address.
Could anybody try this patch? Thanks!
Comment 39 Matthew Garrett 2005-09-21 06:34:08 UTC
No difference on the ECS machine, I'm afraid - on hitting the power button, the
system appears to return to the BIOS.
Comment 40 Shaohua 2005-12-22 20:55:00 UTC
*** Bug 2347 has been marked as a duplicate of this bug. ***
Comment 41 Andrew J. Montalenti 2006-02-27 18:30:24 UTC
this is just a "bump" post to ask, has any work on this been done in recent
kernel versions?  Does anyone need me to test S3 functionality in the bleeding
edge kernels?
Comment 42 Shaohua 2006-02-27 18:37:20 UTC
No, IIRC. This bug is basically impossible to debug without the system at hand.
Comment 43 Andrew J. Montalenti 2006-02-27 18:53:54 UTC
hey, I bought a bunch of these Averatecs for a business.  One my employees
recently broke the screen on one by accident (not a big break, but there's a 1
in. blind spot).  I'm thinking of replacing it.  If I did, and sent you the one
with the broken screen, you could probably debug it using either the existing
screen or using a VGA cable to a monitor.  Would you actually be _willing_ to
debug this if I sent you the hardware? :-)
Comment 44 Shaohua 2006-03-07 16:47:39 UTC
Hi Andrew, I just got confirm I could accept it (yes, Intel takes serious 
about such thing).If you're still willing to send it to me, please drop me an 
email. I'm eager to solve this bug.
Comment 45 Jon Nettleton 2006-03-27 06:24:54 UTC
I am very anxious to get this bug fixed as well.  I am an owner of an Averatec
3220-H1 that does exhibit this problem, and will gladly donate my time to help
do any debugging or testing required.  Feel free to contact me directly if that
is easier.
Comment 46 Andrew J. Montalenti 2006-03-27 09:27:31 UTC
Hey David,

It's going to be a couple of weeks until I can secure the laptop and get ready
to ship it to you.  When this comes closer to reality, I'll contact you for
shipping information.

Sorry for the hold-up!
Comment 47 Jon Nettleton 2006-05-11 17:23:38 UTC
Here is some additional debug information I just stumbled upon, and would like
to see if anyone can confirm it.  I am running 2.6.16-1.2111_FC5 from Fedora and
the following doesn't cause a reboot.

1) Unload cpufreq daemon
2) Load the cpufreq_ondemand module
3) echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Going into suspend mode works as expected.  Pressing the power button to wake up
the machine no longer causes an immediate reboot.  The blue led stops blinking
and that is about it.  Any ideas on what we could do next?
Comment 48 Matthew Garrett 2006-06-18 10:58:23 UTC
Got it. Bit 11 of PM1_STATUS in VIA southbridges is flagged as "Abnormal
power-off". If this is set, the BIOS won't jump back to the OS. Writing the bit
back clears it and the machine then suspends/resumes correctly.
Comment 49 Shaohua 2006-06-18 18:28:29 UTC
Wonderful! So BIOS set the bit and as it's a ignored bit, per ACPI spec OS 
should preserve the bit and write 1, right? I'll report this to Bob.
Comment 50 Matthew Garrett 2006-06-18 18:36:39 UTC
Created attachment 8335 [details]
Attempt to fix up abnormal power-off flag at boot

I believe this ought to do the job
Comment 51 Shaohua 2006-06-18 18:44:47 UTC
I'm wondering if the ACPICA should do this, as this is a ignored bit, and ACPI 
spec said OS writing should preserve the bit. There might be other similar 
Comment 52 Robert Moore 2006-06-20 09:47:54 UTC
Are you saying that the AcpiHwRegisterWrite interface should, in the case of a 
write to this register, do a read/update/write cycle and preserve bit 11? 
(Note, this would mean that any users of this interface would not be able to 
change this bit, but this would be correct according to the ACPI spec.)
Comment 53 Matthew Garrett 2006-06-20 10:55:32 UTC
For suspend to work, the bit needs to be cleared by writing the same bit back
again - is that what you mean by preserving it during the read/write operation?
I guess that would make sense - we'd then end up clearing it in
acpi_enter_sleep_state when acpi_hw_clear_acpi_status gets called, which should
work happily.
Comment 54 Robert Moore 2006-06-20 14:01:50 UTC
Yes. We would preserve it by always writing the same value back to it.

This change would preserve the following bits:


Comment 55 Matthew Garrett 2006-06-20 14:19:43 UTC
Ok, that sounds good to me.
Comment 56 Jon Nettleton 2006-06-21 18:17:05 UTC
I used the fixed patch from the 2.6.17-mm1 today on my KM400 chipset Averatec. 
I am still having the reboot problem on wakeup.  One thing that is definitely
different is pressing a key on the keyboard now brings the machine out of sleep.
 Any other data I can gather to help debug this?
Comment 57 Len Brown 2007-02-05 20:07:56 UTC
The quirk_via_abnormal_poweroff patch in comment #50
was applied to the kernel at some point.

Then it was deemed unnecessary in this thread:
and removed for and 2.6.19.


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