Bug 9025

Created attachment 12834 [details]
output of acpidump

Created attachment 12835 [details]
output of dmesg after successful boot

This may related to the graphics adapter not being initialized properly during the resume.

I'm not sure if s2ram works on MacBooks, but can you try it please (http://en.opensuse.org/s2ram).

s2ram works a little better. 
On resume while X was running, the backlight comes on and I can move the cursor. Nothing else comes back, just the backlight and the cursor. I can move the cursor, but every other second it locks up for about a second.

If I suspend when X is not running, it behaves well, but as soon as I start X I get the behavior described above.

Created attachment 13046 [details]
Output of `s2ram -n`

Have you tried any additional s2ram options?

One more thing: do you use the ATI binary graphics driver or an open source one?

None of the other parameters to s2ram seem to have any effect, but if I don't use vbe_save, the backlight doesn't come back and the machine is hard locked up.

I have the Intel 945Gm graphics controller and I'm using the i915 driver.

Hm, perhaps it's related to Bug #9059.

Can you test 2.6.23-rc9 or the current Linus' tree, please?

I tried it with 2.6.23-rc9, and it is the same.

Please install the current mainline kernel and check if the problem is present in it, thanks.

hah, please attach the lspci output, please try 2.6.27 and see if the problem still exists.

Hi, Mike
    Will you please try the boot option of "acpi_sleep=s3_beep" on the latest kernel and see whether the box can be resumed from S3?
    If the problem still exists, please confirm whether the beep voice can be heard?
    Thanks.

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

Hi, Mike
    Will you please try the debug patch and do the following test if the box still can't be resumed from S3?
    a. echo 25 > /proc/cmos
    b. echo mem > /sys/power/state
    c. press the power button and see whether the system can be resumed.

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

Ping Mike...

Still alive; just really busy. I hope to test the new kernel either tonight or 
tomorrow.

On Mon December 15 2008 11:42:55 pm you wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9025
>
> ------- Comment #15 from yakui.zhao@intel.com  2008-12-15 23:42 -------
> Ping Mike...

can you try command "echo mem > /sys/power/state; dmesg > msg; sync"
and after you do reboot, please check if you can find file 'msg'. If yes, please attach it here. 

Created attachment 19473 [details]
output of lspci

Just tested 2.6.27.10. Suspends fine, but doesn't come back. The backlight doesn't come on, and the screen doesn't seem to do anything at all.

I've attached lspci output. I'm working on all the other things now.

OK, so it seems suspend does work - from X. From the console, I still get a solid black lockup. After I do a successful suspend from X, I can't switch to a VT. The screen is black but the backlight is on. It does look like it's switching modes - there's the usual pause. Also, lid-close suspend doesn't work so my distro (Fedora 9) seems to be doing something weird with their suspend scripts.

I've attached msg from "echo mem > /sys/power/state; dmesg > msg; sync". Do you still want me to apply the CMOS patch and do that?

Created attachment 19474 [details]
msg from "echo mem > /sys/power/state; dmesg > msg; sync" during successful suspend

Hi, Mike
    From the log in comment #21 it seems that the system is resumed from sleeping state successfully. So you needn't try the CMOS patch. 
    If the i915 driver is loaded in console mode, can the screen still be black after resuming?
    Of course another issue is that lid suspend/resume can't work well. Can you confirm whether the windows also work well on this box? From the AML code there exists the _PRW object for the LID device, which means that the system can be waked from S3 by LID device. But unfortunately there is no corresponding _L1D object.
    thanks.
    
     

Hi, Mike
    Will you please do the following test to verify whether the system can be waked by LID device?
    a. Kill the process which is using /proc/acpi/event(use the command of "lsof /proc/acpi/event" to get the process)
    b. echo mem > /sys/power/state; dmesg >dmesg_after; sync; reboot;
    c. close the LID 
    d. After the system is rebooted, please check whether there exists the file of dmesg_after

   Thanks.

Hi, Mike
    As there is no response for nearly two months, the bug will be rejected. 
    In fact the suspend/resume can work well on this box. The remaining issue is that the script related with LID suspend/resume can't work well.
    If it still exists, please reopen this bug and do the test as required in comment #23.
    thanks.