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)
Created attachment 17130 [details] acpidump acpidump output (which BTW reports a "wrong checksum for generic table")
Created attachment 17131 [details] lspci -vxxx
Created attachment 17132 [details] /proc/acpi/wakeup
Created attachment 17133 [details] dmesg
could you please try the patch at http://bugzilla.kernel.org/show_bug.cgi?id=10503#c5 and see if it helps?
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!
Created attachment 17172 [details] patch: disable all pme please try this one. :)
The patch doesn't change anything, the system continues rebooting
Created attachment 17187 [details] dmesg after patch
eeeh where I said "reebooting" I meant "waking up automatically after suspend" :)
Created attachment 17224 [details] patch: show interrupt info after resume Please try this patch on top of the previous one.
Created attachment 17225 [details] patch: show interrupt info after resume Refreshed patch after running checkpatch.pl. Please try this one. :)
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!
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 http://www.lesswatts.org/projects/acpi/faq.php Thanks
Created attachment 17267 [details] dmesg after custom DSDT Yes, the problem still exists
Created attachment 17288 [details] patch: show interrupt info after resume
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.
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
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? Thanks.
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)
Created attachment 17679 [details] try the custom DSDT in which the PTS/WAK object is useless Hi,Diego 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. Thanks.
(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?
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. :)
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
Created attachment 18764 [details] dmesg with "patch: clear acpi events status bit again before suspend"
Created attachment 18765 [details] dmesg with hibernation
(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?
(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.
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?
Created attachment 18825 [details] dmesg from test1
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)
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 http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools-20071116 Thanks.
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?
hmmm, different FADT pointed by RSDT and XSDT. could you please apply the patch from http://marc.info/?l=linux-acpi&m=122445298804762&w=2 and http://marc.info/?l=linux-acpi&m=122445305704837&w=2 rebuilt the kernel, then boot with "acpi_root_table=rsdt" and see if it help?
I applied the patches and booted with "acpi_root_table=rsdt", but no help :( I'm attaching the dmesg in case it helps
Created attachment 19242 [details] dmesg with acpi_root_table=rsdt
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.
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.
would you please try this patch http://article.gmane.org/gmane.linux.usb.general/14317/match=don%27t+enable+wakeup+default+pci+host+controllers
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)
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.
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.
I've tried 2.6.25 - no luck :(
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?
Hi, Diego How about adding the boot option of "acpi_sleep=old_ordering"? Thanks.
No help :/
does the system still wake up immediately when it is not connected to the network?
ping Diego.
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
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.
I did that (no modules loaded in, only SATA and USB are built-in for disk and keyboard) but it doesn't help.
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.
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: http://dlsvr01.asus.com/pub/ASUS/misc/utils/S3USB.zip [I downloaded that, and the registry tweak is this: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\usb] "USBBIOSHACKS"=dword:00000000 "USBBIOSx"=dword:00000000] For more information regarding this issue, please kindly refer to Microsoft KB number KB817900 from the link below: http://support.microsoft.com/kb/817900" 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.
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.
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?
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.
right, then this seems like an ehci driver problem to me. But I think it has already been fixed, no?
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)
Does someone have some pointers related to the USB bug that creates this problem?
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 :)