Bug 11164

Hi, Lorincz
    Will you please confirm whether the system can be resumed correctly if the Lid script is not used?
    After the system is booted, will you please do the following test manually?
    a. Kill the process who is using /proc/acpi/event ( use the command of "lsof /proc/acpi/event" to get the process who is using /proc/acpi/event).
    b. echo mem > /sys/power/state;
    c. press the power button and see whether the system can be resumed from  S3.
    
    It will be great if you can attach the output of dmesg, acpidump, lspci -vxxx.
    Thanks.

Created attachment 17002 [details]
ACPI, dmesg and lspci outputs

Hello,

It is much better without the acpid running. It goes to sleep and after pressing the power button, it wakes up and it seems that the system is waking up correctly except the screen remains blank but I can execute commands so it's just that the screen remains blank. In the attachment I put the output of acpidump, lspci -vxxx, dmesg before entering sleep mode and dmesg after waking up.

Hi, Lorincz
    Thanks for the test. It seems that the system can be resumed correctly by power button.
    Will you please confirm whether the system can be resumed correctly by pressing the LID? Of course the acpid should also be stopped. 
    Thanks.
    

Hello,

The lid button works the same way, but bellow are some comments.

This laptop is playing tricks with me. It may happen that it wakes up differently and I could notice 3 ways the laptop is waking up:

 - the power LED continues to blink, the fan starts spinning and it doesn't listen to commands
 - the power LED stops blinking and turns ON, the fan starts spinning and it doesn't listen to commands
 - the power LED stops blinking and turns ON, the fan starts spinning and it listens to commands except I cannot reboot or poweroff (if I launch one of these commands, there is some hard disk activity but the system won't reboot or poweroff)

The screen doesn't come back in none of the above situations. The conclusion is that it can behave differently. So what I suppose is that there must be some persistent data which survives a power on and power down else I cannot explain why sometimes it behaves in one way and another time in different way. These are similar spooky things which happen with the fan as I explained at bug 8049 (look at comment 55 for example).

By the way, if I can help you somehow with debugging the code I'm in to it but you have to give me some instructions as I'm not familiar with kernel code and kernel development.

Hi, Lorincz
    Thanks for the info. From the description in comment #4 it seems that the LID can also wake up the sleeping system if the LID script is stopped.
    But there also exist some other issues as mentioned in comment #4.
    Will you please enable CONFIG_ACPI_DEBUG in kernel configuration and do the following test?
    a. Kill the process who is using the /proc/acpi/event
    b. echo 0x04A10000 > /sys/module/acpi/parameters/debug_layer && echo 0x1f >/sys/module/acpi/parameters/debug_level
    c. do several cycles of suspend/resume.  
   After the test, please attach the output of dmesg.

   Thanks.
   

Created attachment 17135 [details]
dmesg after resume from sleep

Hello,

Here are two dmesg outputs corresponding to the kernels 2.6.25.6 and 2.6.26 after resume. In these cases the resume worked without display coming back. I cannot send you the dmesg output after the resume doesn't work because obviously the system doesn't listen to commands in this case. I noticed that in case of 2.6.26 the reboot command doesn't work but other commands work (begins the reboot process but hangs at some point).

Created attachment 17473 [details]
Try the customed DSDT

Thanks for the test. It seems that the system can be resumed from suspending state but sometimes it is not very stable. 

Will you please try the custom DSDT and see whether the problem still exists?
How to use the custom DSDT can be found in 
http://www.lesswatts.org/projects/acpi/faq.php
Of course acpid still needs to be stopped.
Thanks.

Sorry for the late response. The situation isn't better with the custom DSDT.

hi, lorincz,
you mentioned that there are three different symptoms, right?
will you please try the latest kernel and make sure what it behaves like?
btw, please do the following test in the latest kernel.
1. cat /sys/power/pm_test 
you should get "[none] core processors platform devices freezer"
2. try the different pm_test mode each time and see if the test is okay.
e.g. echo core > /sys/power/pm_test; echo mem > /sys/power/state;
wait for about 10 secs and see if the system can get back.
please attach the dmesg after the tests.

Hi, Lorincz
    Please try the test as suggested in comment #10.
    From the test it seems that the system can be resumed if LID script is disabled.  But there exist some other issues as described in comment #4. 
    From the issues mentioned in comment #4 it seems that the problem is related with FAN. 
    Will you please add the boot option of "acpi.power_nocheck=1" on the latest kernel and see whether the problem still exists? (Of course please don't use the LID script in your test).
    thanks.
    

Created attachment 18927 [details]
dmesg for 2.6.28-rc5

Hello,

I don't know if I had to do the test with or without the custom DSDT table included in the kernel. I tested without including the custom DSDT table in the kernel. I used kernel 2.6.28-rc5. Here is what I noticed:

1. There is no pm_test file in the /sys/power directory
2. Doing echo mem > /sys/power/state causes the laptop to suspend to RAM. Then after pushing the power button the system wakes up this way: power led remains in blinking state (as during in the suspended state), the fan starts spinning, the screen remains blank and the system doesn't react to any command (that I try to launch blindly as I can see nothing on the screen)

I tried the test a few times and the behaviour is the same every time. I also attached the dmesg output obtained after system startup.

Hi, Lorincz
    When you do the test as suggested in comment #10, you should enable "CONFIG_PM_DEBUG" in kernel configuration.
    Do you mean that the following symptom still exists in your test?
    a. screens remains blank
    b. power led remains in blinking state

    Is the above test done in console mode/graphics mode? Please do it in graphics mode.
    Thanks.

Created attachment 18957 [details]
dmesg output

Hello,

I did the following tests:

echo core > /sys/power/pm_test ;echo mem > /sys/power/state
echo core > /sys/power/pm_test ;echo mem > /sys/power/state (I did this 2 times)
echo processors > /sys/power/pm_test ;echo mem > /sys/power/state
echo platform > /sys/power/pm_test ;echo mem > /sys/power/state
echo devices > /sys/power/pm_test ;echo mem > /sys/power/state
echo freezer > /sys/power/pm_test ;echo mem > /sys/power/state

I launched the test while in X as you told me to do the tests in graphics mode. For each of the above commands, the system began the process of going to sleep (I was go out from the desktop and on the console was displayed something like "Freezing processes" and so on) then the system got back to my desktop without doing anything.

Hi, Lorincz
    From the test result it seems that the system can be wakeup from S3 by power button.
    If the LID script is not used, the system is also wakeup from S3 by LID. But it is not very stable. Maybe it is related with LID.
    Will you please try the following test?
    a. kill the process which is using /proc/acpi/event (use the command of "lsof /proc/acpi/event to get the process using the /proc/acpi/event)
    b. echo 0x090004 > /sys/module/acpi/parameters/debug_layer ; echo 0x01f > /sys/module/acpi/parameters/debug_level
    c. cat /proc/acpi/event > event_log ; please don't press CTRL +C until step d is finished
    d. press the LID button several times and see whether the system is normal

    After the test , please attach the output of event_log, dmesg.
    Thanks.

Created attachment 19047 [details]
event_log file and corresponding dmesg output

Hi,

When I press the LID the monitor is blanked, when I release it the monitor comes back but as far as could notice nothing else happens, the system is working fine after pressing the LID. Also I have to mention that waking up from S3 by pressing LID or the power button makes no difference: the power LED remains in blinking state, the monitor remains blank, the fan starts spinning and the keyboard is not responding to commands (for example if I press the caps lock nothing happens, that is the caps lock LED does nothing).

Hi, Lorincz
    Thanks for the test.
    From the test it seems that the LID event can be reported correctly. 
    But the issue about S3 still exists. Do you mean that the issue still exists regardless of using Power button or LID? This seems contradictory with the comment #2.
    In the comment #2 the system can be resumed by pressing power button. Of course the monitor remains blank.

    Will you please add the boot option of "acpi_sleep=s3_beep" and do the following test?
    a. kill the process which is using the /proc/acpi/event
    b. dmesg > dmesg_before; echo mem > /sys/power/state; dmesg >dmesg_after; reboot;
    c. press the power button or LID and confirm whether the beep voice can be heard and the system can be rebooted?
    
    After the test, please attach the output of dmesg_after/dmesg_before.
    Thanks.
    
    

Hi,

Using kernel 2.6.25.6 sometimes happened that the system woke up like this:

 - the power LED stopped blinking
 - the screen remained blank
 - I could enter commands (if I entered a command like ls then I saw the hard disk LED indicating disk traffic)

But this happened only sometimes, sporadically, but most of the time the system woke up like this:

 - the power LED remained in blinking state
 - the screen remained blank
 - the system doesn't react to commands

With kernel 2.6.28-rc5, the system woke up only the secound way (the system never woke up in a state in which it would respond to commands).
I've done the test as you recommended in comment 17, the result is that dmesg_after does not get created and I could not hear any beep. I used only the power button to wake up.

Created attachment 19309 [details]
use the RTC cmos area to track where the suspend/resume hangs

Hi, Lorincz
    Thanks for the test.From your test the system can't be resumed at most time. And there is no beep voice.
    Will you please try the debug patch on the latest kernel(2.6.28-rc7) and do the following test?
   a. echo 25 > /proc/cmos
   b. echo mem > /sys/power/state; 
   c. press power button and see whether the system can be resumed. 

   If it can't be resumed correctly, please reboot the system. After the system
is rebooted, please cat /proc/cmos and attach the output of dmesg.
   thanks.

Created attachment 19326 [details]
Dmesg output 2.6.28-rc8

Hello,

The system didn't wake up. cat /proc/cmos displays this:

mcount=1, time=3ffffc20

The dmesg is attached.

Hi, Lorincz
    Thanks for the test. From the log in comment #20 it seems that the BIOS doesn't transfer control to the pre-defined waking vector. But the value is not what we expected.
    >mcount=1, time=3ffffc20 ( The last jiffies is written into the CMOS. But it seems so large)
    Will you please do the test as mentioned in comment #19 again?
    After do the command of "echo 25 > /proc/cmos", please also get the dmesg. At the same time the boot option of "printk.time=1" had better be added.
    thanks.
    
    

Created attachment 19342 [details]
dmesg before and after sleep

Hi,

I've added the printk.time=1 boot parameter and got the dmesg output after launching echo 25 > /proc/cmos but before launching echo mem > /sys/power/state. Also got dmesg output after entering sleep and rebooting the laptop(the system doesn't wake up from sleep). The output of cat /proc/cmos is the same, that is:

mcount=1, time=3ffffc20

Created attachment 19352 [details]
use the RTC cmos area to track where the suspend/resume hangs

Will you please try the debug patch and do the test as mentioned in comment #19 again?
   Thanks.

Hi, lorincz
    Thanks for the test.
    In theory the mcount should be 25 after catting /proc/cmos. In the debug patch the RTC cmos area of 0x40-44 is used.  Maybe this area is also used by BIOS.
    In the new patch the RTC cmos area of 0x20-24 is used.
    Will you please try it again?
    thanks.

Created attachment 19360 [details]
dmesg output

Hi,

The situation is still the same and the system isn't waking up, but mcount and time are different now as you can see in the dmesg attached.

Hi, Lorincz
    Thanks for so quick response. From the test the value of mcount is still what we expected. As it is incorrect, I can't judge whether the suspend/resume hangs. In such case there exist the following two possibilities:
    a. Maybe the BIOS already transfers control to the pre-defined waking vector(this works in real mode) and the OS is not resumed correctly.(In real mode the 0xA8A8A8A8 is written to 0x21-24 RTC cmos area. The 0x20 area is not touched.)  
    b. Maybe it hangs in BIOS. In such case before the system enters sleeping state, the system jiffies will be written to 0x21-24 RTC cmos area. 
    
    When the system is restarted, the RTC cmos area of 0x20-24 is rewritten by BIOS. As the value of mcount is incorrect, we can't know the correct value that is written to 0x20-24 RTC cmos area.
    
    Do you have opportunity to know which part of RTC cmos area is available for OS?(It won't be modified by BIOS).
    If so, it can be used to track whether the suspend/resume hangs.
    thanks.
    

Created attachment 19367 [details]
use the RTC cmos area to track where the suspend/resume hangs

will you please try the updated debug patch?
    In the updated patch the 0x60-64 RTC cmos area is used.
    Thanks.

Created attachment 19376 [details]
dmesg output

The system doesn't wake up but mcount looks better as I think the expected value is 25. Does this mean that the space allocated for the OS in the waking vector is 0x60-0x64? If not then please give me some hints on how could I find out the correct area. The BIOS image wouldn't be of any help? It is at:

http://support.fujitsu-siemens.com/com/support/downloads.html

You have to look there for amilo l1310g. I also have windows XP installed on the laptop in which the suspend/resume works. Could I get some helpful information from windows?

Hi, Lorincz
    Thanks for the test.
    The waking vector is not set in the RTC cmos area of 0x60-64. It is set in FACS table, which is a specific ACPi table. The RTC cmos area of 0x60-64 is used in the debug patch. Its purpose is to track where suspend/resume hangs.
    For example: When the system begin to suspend, the current jiffies is written. When the BIOS transfers control to OS and OS is in real mode, the 0xA8A8A8A8 is written. 
    According to the content of RTC cmos area(0x60-0x64) we can judge where suspend/resume hangs. In BIOS or OS.
    
    thanks for the confirmation that the suspend/resume can work well on windows XP.
    Thanks.
    

Hi, Lorincz
    When the RTC cmos area of 0x60-64 is used, the value of mcount is what we expected. But the value of jiffies is so large that I can't know whether it is correct. If it is correct, it seems that the suspend/resume hangs in BIOS. If it is incorrect, it is difficult to judge where suspend/resume hangs.
    
    At the same time there is another weird issue. From the acpidump in comment #2 we can know that the address of FACS table is 37EB4FC0. And the system can be resumed correclty. The only issue is that the screen remains black. And IMO this is related with ATI graphics driver.
    But from the dmesg log in comment #12,14 the address of FACS table is 77EB4FC0.
    Please check whether the hardware is changed on your box.
    
  

Created attachment 19482 [details]
Windows XP registry screenshot

Hello,

I've made a memory upgrade on the laptop, I had 2 512MB modules and replaced them with 2 1GB memory modules, probably that's the reason for FACS table address change. This change happened approximately 2 months ago. Attached you can find a screenshot of the windows XP registry with ACPI data, please let me know if there is some data which can be helpful.

P.S. Could you tell me what represent those jiffies you are talking about? Thanks.

Hi, Lorincz
    Thanks for the explanation.
    Before the system enters the sleeping state, the current jiffies will be written to the RTC CMOS area. After the BIOS transfers control to OS in real mode, the 0xA8A8A8A8 will be written.  After the protected mode is entered, the 0x9C9C9C9C will be written.
    But from the output it seems that the value is 0xffff3587. It is beyong what we expected.
    In such case it seems that it is also changed by BIOS. And we don't know the true value what we have written.
    thanks.

Created attachment 19556 [details]
use the RTC cmos area(0x90-0x94) to track where the suspend/resume hangs

On the box based on intel chipset there exists the extended RTC cmos area, which can be used to track where suspend/resume hangs.
I don't know whether there exists the extended RTC CMOS area on this box(based on ATI chipset).
   Will you please try the debug patch and do the test mentioned in comment #19?
    In this debug patch the extended RTC cmos area (0x90-0x94) is used.
   Thanks.

Hello,

It seems that the extended RTC area doesn't work for this system. The system didn't wake up but the situation was worse as it was needed to reset the BIOS data by removing the battery from the motherboard because I was not able to boot the laptop at all.

Hi, Lorincz
    Thanks for the test. It seems that there is no extended RTC CMOS area.
    Now I understand the log in comment #28. The test result is what we expected. And it is correct. The value(0xffff3587) is written to RTC cmos area before entering suspend. But unfortunately after the power button is pressed, BIOS doesn't transfer the control to the waking vector predefined by OS.
    
    It is very interesting that windows can work well on this box.
    I will try to look at this issue.
   
    Thanks.

Hello,

Thanks for your help and I'm sorry to say that I sold that fujitsu-siemens laptop because suspend to RAM doesn't work modem driver (I still need modem connection sometimes :D) doesn't exist either for linux... so I bought a dell laptop which is fully working on linux :)... I hope that somebody with a amil laptop will offer help for testing.

Hi, Lorincz
    Thanks for the response and notication that the box was sold.
    Now I have no idea about this bug. From the test log it seems that sometimes the box can be resumed.(For example: in comment #7). And sometimes it can't be resumed and hang in BIOS.(For example: in comment #28).
    As the box is not in your hand, the bug will be rejected. If someone has the same issue on Amilo L1310G, they can open a new bug.
    
    Thanks for the test.