Bug 11268

Summary: S3: immediate wakeup - P5L-VM Asus mainboard
Product: Drivers Reporter: Diego Calleja (diegocg)
Component: USBAssignee: Greg Kroah-Hartman (greg)
Severity: normal CC: acpi-bugzilla, gabriel, jbarnes, rui.zhang
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.27-rc2-00020-g685d87f Subsystem:
Regression: No Bisected commit-id:
Bug Depends on:    
Bug Blocks: 56331    
Attachments: acpidump
lspci -vxxx
patch: disable all pme
dmesg after patch
patch: show interrupt info after resume
patch: show interrupt info after resume
dmesg after patch that shows interrupt info after resume
Try the custom DSDT
dmesg after custom DSDT
patch: show interrupt info after resume
patch: show interrupt info before suspend
dmesg after the latest two patches
use the attached tool to read some I/O ports
try the custom DSDT in which the PTS/WAK object is useless
patch: clear acpi events status bit again before suspend
dmesg with "patch: clear acpi events status bit again before suspend"
dmesg with hibernation
dmesg from test1
dmesg with acpi_root_table=rsdt

Description Diego Calleja 2008-08-07 12:19:45 UTC
Earliest failing kernel version: It never worked
Distribution: Ubuntu
Hardware Environment: 945G system with Intel Core 2 CPU (P5L-VM Asus mainboard)
Problem Description:

This problem has been always there since i bought this hardware, but I never reported it until now. The problem is that when I do echo mem > /sys/power/mem, the system suspends well, but it wakes up again inmmediately after the fans and harddisk have stopped. Its always reproducible.

CONFIG_ACPI_DEBUG and all the PM debug machinery is enabled. I've boot up with acpi.debug_level=0x0800001f and acpi.debug_layer=0x080004 (as I saw that recommendation in other bug reports while searching a duplicate)
Comment 1 Diego Calleja 2008-08-07 12:20:53 UTC
Created attachment 17130 [details]

acpidump output (which BTW reports a "wrong checksum for generic table")
Comment 2 Diego Calleja 2008-08-07 12:21:59 UTC
Created attachment 17131 [details]
lspci -vxxx
Comment 3 Diego Calleja 2008-08-07 12:24:32 UTC
Created attachment 17132 [details]
Comment 4 Diego Calleja 2008-08-07 12:24:55 UTC
Created attachment 17133 [details]
Comment 5 Zhang Rui 2008-08-07 18:24:15 UTC
could you please try the patch at
and see if it helps?
Comment 6 Diego Calleja 2008-08-08 07:09:11 UTC
The patch doesn't apply to current Linus' -git. I've tried to fix it manually, but there's not even a call to call_platform_enable_wakeup() in the whole pci.c file, so I don't know what to do.

Thanks for the quick answer! 
Comment 7 Zhang Rui 2008-08-10 18:11:52 UTC
Created attachment 17172 [details]
patch: disable all pme

please try this one. :)
Comment 8 Diego Calleja 2008-08-12 07:34:34 UTC
The patch doesn't change anything, the system continues rebooting
Comment 9 Diego Calleja 2008-08-12 07:35:26 UTC
Created attachment 17187 [details]
dmesg after patch
Comment 10 Diego Calleja 2008-08-12 07:44:55 UTC
eeeh where I said "reebooting" I meant "waking up automatically after suspend" :)
Comment 11 Zhang Rui 2008-08-13 19:50:20 UTC
Created attachment 17224 [details]
patch: show interrupt info after resume

Please try this patch on top of the previous one.
Comment 12 Zhang Rui 2008-08-13 19:56:54 UTC
Created attachment 17225 [details]
patch: show interrupt info after resume

Refreshed patch after running checkpatch.pl.
Please try this one. :)
Comment 13 Diego Calleja 2008-08-14 13:38:58 UTC
Created attachment 17249 [details]
dmesg after patch that shows interrupt info after resume

Complete dmesg. The relevant part is:

 hwsleep-0326 [03] enter_sleep_state     : Entering sleep state [S3]
ACPI: Fixed event: Status=00, Enable=00
ACPI: GPE0: Status=00, Enable=00
ACPI: GPE8: Status=20, Enable=00
ACPI: GPE10: Status=03, Enable=00
ACPI: GPE18: Status=DD, Enable=00
Back to C!
Comment 14 ykzhao 2008-08-15 00:07:14 UTC
Created attachment 17259 [details]
Try the custom DSDT

Will you please try the custom DSDT and see whether the problem still exists?
Please boot the system with the option of "printk.time=1 acpi.debug_layer=0x0084 acpi.debug_level=0x1F". 

How to use the custom DSDT can be found in 

Comment 15 Diego Calleja 2008-08-15 07:25:47 UTC
Created attachment 17267 [details]
dmesg after custom DSDT

Yes, the problem still exists
Comment 16 Zhang Rui 2008-08-17 22:43:34 UTC
Created attachment 17288 [details]
patch: show interrupt info after resume
Comment 17 Zhang Rui 2008-08-17 22:44:41 UTC
Created attachment 17289 [details]
patch: show interrupt info before suspend

Please apply this patch on top of the last one.
and attach the dmesg output after s3.
Comment 18 Diego Calleja 2008-08-18 12:38:47 UTC
Created attachment 17313 [details]
dmesg after the latest two patches

ok, this is the dmesg after those two patches. I only applied those two, and I didn't use the customized dsdt (should have I used it?). I used the acpi.debug_layer=0x0084 acpi.debug_level=0x1F parameters.

printks at the suspend/resume time:

[   74.562001] agpgart-intel 0000:00:00.0: LATE suspend
[   74.562001] ACPI: Fixed event: Status=00, Enable=120
[   74.562001] ACPI: GPE0: Status=00, Enable=00
[   74.562001] ACPI: GPE8: Status=00, Enable=00
[   74.562001] ACPI: GPE10: Status=03, Enable=00
[   74.562001] ACPI: GPE18: Status=DD, Enable=00
[   74.562001] ACPI: Fixed event: Status=00, Enable=00
[   74.562001] ACPI: GPE0: Status=00, Enable=00
[   74.562001] ACPI: GPE8: Status=20, Enable=00
[   74.562001] ACPI: GPE10: Status=03, Enable=00
[   74.562001] ACPI: GPE18: Status=DD, Enable=00
[   74.562001] ACPI: PM1Acontrol 00000001, PM1Bcontrol 00000001
[   74.562001] Back to C!
[   74.562001] agpgart-intel 0000:00:00.0: EARLY resume
Comment 19 ykzhao 2008-08-26 19:48:37 UTC
Created attachment 17471 [details]
use the attached tool to read some I/O ports

Will you please use the attached tool to get the following info?
   a. Before the system enters the sleeping state.
     ./ior --addr 0x804 --width 16    (0x804 is PM1a_control register)
     ./ior --addr 0x830 --width 16    
   b. after the system is resumed
     ./ior --addr 0x804 --width 16
     ./ior --addr 0x830 --width 16

   Will you please confirm whether the hibernate can work on your laptop?
Comment 20 Diego Calleja 2008-08-27 14:00:48 UTC
root@diego-desktop:/tmp/io_op# ./ior --addr 0x804 --width 16

 the value of IO port 0x804 is 1
root@diego-desktop:/tmp/io_op# ./ior --addr 0x830 --width 16

 the value of IO port 0x830 is 202b

root@diego-desktop:/tmp/io_op# echo "mem" > /sys/power/state
root@diego-desktop:/tmp/io_op# ./ior --addr 0x804 --width 16

 the value of IO port 0x804 is 1
root@diego-desktop:/tmp/io_op# ./ior --addr 0x830 --width 16

 the value of IO port 0x830 is 202b

I'll try hibernate later (btw, it's not a laptop, it's a desktop)
Comment 21 ykzhao 2008-09-08 01:31:20 UTC
Created attachment 17679 [details]
try the custom DSDT in which the PTS/WAK object is useless

   From the acpidump we can know that in the original DSDT table the PTS/WAK object will call several ACPI methods, in which some hardware registers will be accessed.
   >Method (PTS, 1, NotSerialized)
        If (Arg0)
      >      \_SB.PCI0.SBRG.SIOS (Arg0)
      >     \_SB.PCI0.NPTS (Arg0)
      >      \_SB.PCI0.SBRG.SPTS (Arg0)
      > }
    Will you please try the custom DSDT and see whether the resume can work on your machine? 
    How to use the custom DSDT is described in the comment #14.
Comment 22 Diego Calleja 2008-09-13 11:52:23 UTC
(Sorry for the delay: I had connectivity problems)

This DSDT worked - the system suspends. But.....it doesn't wake up. Keyboard, mouse...nothing wakes up the system. Pressing the power button doesn't wakes up the system either: It boots up the system. Which makes me think that maybe the system didn't really suspend, it just powered off?
Comment 23 Zhang Rui 2008-10-30 20:56:48 UTC
Created attachment 18542 [details]
patch: clear acpi events status bit again before suspend

the dmesg shows that there are still some pending ACPI interrupts after clearing all the status bit.
I suspect that BIOS issues some wakeup events and pulls the system back once it enters a sleep state.
please try this patch which clears the interrupts again before suspend.

BTW: no custom DSDT needed.

And please try hibernation and see if it has the same issue. :)
Comment 24 Diego Calleja 2008-11-09 14:56:46 UTC
Sorry for the delay - didn't see the email.

I've tried the patch, and it doesn't work :( The system reboots alone as soon as I suspend. I've also tried hibernation, and it works ok (well, other than my tablet not working, but thats a different issue)

I'll attach both dmesgs
Comment 25 Diego Calleja 2008-11-09 14:58:23 UTC
Created attachment 18764 [details]
dmesg with "patch: clear acpi events status bit again before suspend"
Comment 26 Diego Calleja 2008-11-09 14:59:00 UTC
Created attachment 18765 [details]
dmesg with hibernation
Comment 27 Zhang Rui 2008-11-09 18:44:35 UTC
(In reply to comment #24)
> I've tried the patch, and it doesn't work :( The system reboots alone as soon
> as I suspend. )

you means the system reboots immediately instead of resuming when suspending to memory?
but the dmesg in comment #25 shows that the system can resume back from suspend.

Plus, can you retry without the wacom driver loaded?
Comment 28 Diego Calleja 2008-11-10 09:13:11 UTC
(In reply to comment #27)

The system doesn't reboots immediately, it suspends and resumes alone as soon as the suspend is finished. I've also tried unloading the wacom module, with no luck.
Comment 29 Zhang Rui 2008-11-10 17:10:09 UTC
please do the following tests,
1.please set CONFIG_ACPI_DEBUG and attach the dmesg output after a suspend/resume cycle.
2. please boot with kernel parameter "acpi_sleep=s3_beep", can you hear the beep when the laptop resumes back?
3. please "cat /sys/power/pm_test", then "echo core > /sys/power/pm_test".
run "echo mem > /sys/power/state" to suspend and wait for the laptop to resume, is the symptom this time the same as before?
Comment 30 Diego Calleja 2008-11-12 09:29:31 UTC
Created attachment 18825 [details]
dmesg from test1
Comment 31 Diego Calleja 2008-11-12 09:36:50 UTC
Test 1: dmesg attached in comment #30

Test 2: Yes, I can hear the beeps when the system resumes back (BTW, it's not a laptop, it's a desktop machine)

Test 3: Yes, the symptoms are different. Previously, the system would suspend completely - screen, fans, hard disk - and resume automaticall as soon as the suspend is done. With the commands which you told me to run, the system suspends: The screen is black, the hard disk spins off. But the fans continue working, they never stop. And instead of resuming back inmmadiately, it waits 7 seconds to spin up the hard disk and complete the resume, as the dmesg shows:

[  434.829309] ata3.00: configured for UDMA/133
[  434.829313] ata3: EH complete
[  434.843283] ata1.00: configured for UDMA/33
[  441.928647] sd 2:0:0:0: [sda] 234493056 512-byte hardware sectors: (120 GB/111 GiB)
Comment 32 ykzhao 2008-12-07 18:13:16 UTC
Hi, Diego
    Sorry for the late response.
    Will you please confirm whether the suspend/resume can work well on windows?
    From the acpidump it seems that there exist both RSDT and XSDT table. Will you please use the latest dump tool to get the acpidump?
    The latest dump tool can be found in 

Comment 33 Diego Calleja 2008-12-09 15:21:11 UTC
Sorry for my delay! I don't know if suspend/resume works on windows, never used it in this box - i'll try to find a install disk and report back as soon as possible.

WRT your request to use the latest dump tool...I see in the URL "http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools-20071116"
that it's the version 20071116 of acpidump the one I must use...but in my system (ubuntu stable) I have that same version:
ii  acpidump                                   20071116-1           utilities 

so it seems i'm already using the latest version of acpidump. How can I extract the RSDT and XSDT table that you're asking? acpidump -t RSDT and acpidump -t XSDT returns the following:

diego@diego-desktop:~$ sudo acpidump -t RSDT
Wrong checksum for OEMB
Wrong checksum for OEMB!
RSDT @ 0x3f790000
  0000: 52 53 44 54 38 00 00 00 01 2b 41 5f 4d 5f 49 5f  RSDT8....+A_M_I_
  0010: 4f 45 4d 52 53 44 54 20 06 07 00 06 4d 53 46 54  OEMRSDT ....MSFT
  0020: 97 00 00 00 00 02 79 3f 90 03 79 3f 40 e0 79 3f  ......y?..y?@.y?
  0030: 00 5e 79 3f 40 5e 79 3f                          .^y?@^y?

diego@diego-desktop:~$ sudo acpidump -t XSDT
Wrong checksum for OEMB
XSDT @ 0x3f790100
  0000: 58 53 44 54 4c 00 00 00 01 7b 41 5f 4d 5f 49 5f  XSDTL....{A_M_I_
  0010: 4f 45 4d 58 53 44 54 20 06 07 00 06 4d 53 46 54  OEMXSDT ....MSFT
  0020: 97 00 00 00 90 02 79 3f 00 00 00 00 90 03 79 3f  ......y?......y?
  0030: 00 00 00 00 40 e0 79 3f 00 00 00 00 00 5e 79 3f  ....@.y?.....^y?
  0040: 00 00 00 00 40 5e 79 3f 00 00 00 00              ....@^y?....

Wrong checksum for OEMB!

Are the checksum errors something to worry about?
Comment 34 Zhang Rui 2008-12-09 18:05:55 UTC
hmmm, different FADT pointed by RSDT and XSDT.

could you please apply the patch from
rebuilt the kernel, then boot with "acpi_root_table=rsdt"
and see if it help?
Comment 35 Diego Calleja 2008-12-10 14:53:29 UTC
I applied the patches and booted with "acpi_root_table=rsdt", but no help :( 

I'm attaching the dmesg in case it helps
Comment 36 Diego Calleja 2008-12-10 14:53:56 UTC
Created attachment 19242 [details]
dmesg with acpi_root_table=rsdt
Comment 37 Diego Calleja 2008-12-10 14:55:29 UTC
BTW, I also tried updating the BIOS to the latest version and disabling the "enable ACPI 2.0" BIOS option - no luck, the problem persists.
Comment 38 Zhang Rui 2008-12-10 19:46:04 UTC
sigh, I have no idea how to debug this bug.

this is a BIOS issue to me. because it generates a wakeup event immediately after suspend.
Btw: the fixed event enable bit is also changed during resume according to comment #18.
Comment 40 Diego Calleja 2009-02-03 08:09:08 UTC
I tried (I saw it is included in the current Linus -git tree, which is the tree I'm runnning right now), but it doesn't help :(

[  119.236780] CPU 1 is now offline
[  119.236782] SMP alternatives: switching to UP code
[  119.342140] CPU0 attaching NULL sched-domain.
[  119.342144] CPU1 attaching NULL sched-domain.
[  119.344388] CPU0 attaching NULL sched-domain.
[  119.344555] CPU1 is down
[  119.344563] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[  119.344563] Back to C!
[  119.344563] pci 0000:00:02.0: restoring config space at offset 0x1 (was 0x900007, writing 0x900003)
Comment 41 Gabriel Owczarski 2009-02-18 22:39:15 UTC
I have the same problem on my Asus A6M notebook. On 2.6.25 kernel it work very well, but on 2.6.27 and 2.6.28 I cant suspend to ram.
Comment 42 Zhang Rui 2009-02-19 17:18:49 UTC
Diego, can you please verify if s3 works in 2.6.25 kernel?

Gabriel, I know it may be difficult, but it would be great if you can run git-bisect to see which commit introduces this regression.
Comment 43 Diego Calleja 2009-02-23 06:51:15 UTC
I've tried 2.6.25 - no luck :(
Comment 44 Zhang Rui 2009-02-23 23:14:25 UTC
well, I've got no idea what to do next.
everything of ACPI seems to work normally.
len, can you have a look at this issue?
Comment 45 ykzhao 2009-03-18 01:00:31 UTC
Hi, Diego
    How about adding the boot option of "acpi_sleep=old_ordering"?
Comment 46 Diego Calleja 2009-03-23 11:16:14 UTC
No help :/
Comment 47 Len Brown 2009-04-01 01:47:44 UTC
does the system still wake up immediately when it is not connected to the network?
Comment 48 Zhang Rui 2009-05-05 06:36:13 UTC
ping Diego.
Comment 49 Diego Calleja 2009-05-05 13:21:01 UTC
Sorry, I didn't see Len's question!

Yes, it still wakes up when it's not connected to the network - in fact i'm a dialup user, I use a 56k serial modem, not a network card
Comment 50 Zhang Rui 2009-05-22 03:01:11 UTC
please log into single user mode,
echo mem > /sys/power/state
does the problem still exist?
please build the drivers to modules instead of build in as more as possible before this test.
Comment 51 Diego Calleja 2009-05-23 16:13:53 UTC
I did that (no modules loaded in, only SATA and USB are built-in for disk and keyboard) but it doesn't help.
Comment 52 Diego Calleja 2009-06-19 13:37:46 UTC
Hi, I've found a interesting FAQ entry in the ASUS support site which may finally decipher this problem. A guy has exactly the same problem I'm suffering, except that this guy is using Vista: "My system fails to enter Standby mode under VISTA OS with pure settings (Untouched freshly installed OS, all BIOS settings set to default, and jumpers are set to default settings as according to user manual.)  System returns right back to the system every time when I tried to enter Standby mode."

Answer given by ASUS: "If you have recently updated your BIOS, please clear RTC RAM (CLRTC) jumper first, and load default at the BIOS menu. Sometimes, clearing RTC RAM (CLTRC) jumper and load BIOS default can help eliminate some of unexpected phenomenons.

If this phenomenon still persists, it may be caused by VISTA OS.  VISTA does not allow system to enter Standby mode, if "Allow this device to bring the computer out of standby" for an USB or PS/2 wake-supported device (such as mouse or keyboard) has been checked under "Device Manager", while the USB or PS/2 port has not switched its power mode to +5VSB that allows delivery of standby power to USB or PS/2 ports under soft OFF state. Because VISTA enables this standby option per default, and motherboards often set USB power modes to +5V at the same time, these two settings may result in conflict, hence resulting this phenomenon.

To resolve this, simply uncheck "Allow this device to bring the computer out of standby" for your USB mouse and PS/2 keyboard under "Device Manager", if you do not desire to wake the system via your USB mouse and/or PS/2 keyboard.

If you would like to wake your system from USB or PS/2 devices, please turn off your PC, set the appropriate USB port or PS/2 port jumper from +5V  to +5VSB. Please follow the instructions in your user manual. Then your system will be able to enter and wake from standby mode as you desire. "

I can tell that clearing the RTC doesn't work for me, I've already done that many times.
Comment 53 Diego Calleja 2009-06-19 13:50:18 UTC
A similar problem but for XP (I could swear I already looked the faq many time ago!): "My system always resume immidately after entering S3 mode under Windows XP when having any USB devices connected to my system. What can I do to resolve this problem?"

Answer from Asus: "This could be caused by a known issue inside Windows XP.
Please simply apply the registry fix from the link below to fix this problem:

[I downloaded that, and the registry tweak is this:

For more information regarding this issue, please kindly refer to Microsoft KB number KB817900 from the link below:

A related KB: http://support.microsoft.com/kb/841858

Which seems to be the same process suggested in the previous FAQ which I posted here.
Comment 54 Gabriel Owczarski 2009-06-21 14:13:05 UTC
How to confirm this information? On notebook there's no jumpers to switch from +5V to +5VSB.
On higher version kernel still no luck (2.6.30). System is going to sleep mode (S3), when done, after ~500ms going up.
Comment 55 Zhang Rui 2009-06-22 01:06:57 UTC
I don't think it's the USB devices that breaks S3 because we've already fixed that bug.
but could you please make a double check? does the problem still exist if you load with nousb?
Comment 56 Gabriel Owczarski 2009-06-22 05:07:44 UTC
Yes, it's problem with USB. When I unload ehci_hcd module S3 works perfectly. With loaded this module, system is going sleep and immidiatelly waking up.
Comment 57 Zhang Rui 2009-06-22 05:20:01 UTC
right, then this seems like an ehci driver problem to me.
But I think it has already been fixed, no?
Comment 58 Diego Calleja 2009-06-22 14:59:22 UTC
With nousb the immediate wakeup also disappears for me (I can't get it back to life though - the PS2 keyboard leds blink like if I had a kernel oops, but I can't see anything in the screen. With USB support I get an immediate wakeup but no oops)
Comment 59 Diego Calleja 2009-07-01 19:37:57 UTC
Does someone have some pointers related to the USB bug that creates this problem?
Comment 60 Diego Calleja 2009-09-17 15:49:39 UTC
Well, it seems that disabling the wakeup events from USB devices makes it work well with 2.6.31-05315-gab86e57. So if anything the only thing that shpuld be fixed is USB.

It has been a year since I posted this bug...thanks to all the people involved :)