Bug 9025 - MacBook Black doesn't resume from suspend to RAM
Summary: MacBook Black doesn't resume from suspend to RAM
Alias: None
Product: Power Management
Classification: Unclassified
Component: Hibernation/Suspend (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: ykzhao
Depends on:
Blocks: 7216
  Show dependency tree
Reported: 2007-09-15 15:41 UTC by Mike Harris
Modified: 2009-02-11 21:55 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.23-rc6
Regression: ---
Bisected commit-id:

output of acpidump (101.99 KB, text/plain)
2007-09-15 15:42 UTC, Mike Harris
output of dmesg after successful boot (21.41 KB, text/x-log)
2007-09-15 15:43 UTC, Mike Harris
Output of `s2ram -n` (479 bytes, text/plain)
2007-10-04 23:37 UTC, Mike Harris
use the RTC cmos area to track where the suspend/resume hangs (5.60 KB, patch)
2008-12-04 00:59 UTC, ykzhao
Details | Diff
output of lspci (1.86 KB, text/plain)
2008-12-24 13:21 UTC, Mike Harris
msg from "echo mem > /sys/power/state; dmesg > msg; sync" during successful suspend (30.29 KB, text/plain)
2008-12-24 13:48 UTC, Mike Harris

Description Mike Harris 2007-09-15 15:41:51 UTC
Distribution: Fedora 7
Hardware Environment: MacBook Black (first gen)
Problem Description: MacBook will not wake up from suspend. It goes to sleep fine, but just locks up on wakeup. The screen never turns back on, it will not respond to key presses, and the network stays down.

Steps to reproduce:
echo "mem" > /sys/power/state
Machine will successfully go to sleep.
Press power button to wake it up.
Machine does not wake up.

I've attached dmesg and acpidump.
Comment 1 Mike Harris 2007-09-15 15:42:29 UTC
Created attachment 12834 [details]
output of acpidump
Comment 2 Mike Harris 2007-09-15 15:43:09 UTC
Created attachment 12835 [details]
output of dmesg after successful boot
Comment 3 Rafael J. Wysocki 2007-09-16 12:26:00 UTC
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).
Comment 4 Mike Harris 2007-10-04 23:35:51 UTC
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.
Comment 5 Mike Harris 2007-10-04 23:37:45 UTC
Created attachment 13046 [details]
Output of `s2ram -n`
Comment 6 Rafael J. Wysocki 2007-10-05 06:27:22 UTC
Have you tried any additional s2ram options?
Comment 7 Rafael J. Wysocki 2007-10-05 06:28:08 UTC
One more thing: do you use the ATI binary graphics driver or an open source one?
Comment 8 Mike Harris 2007-10-05 17:15:02 UTC
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.
Comment 9 Rafael J. Wysocki 2007-10-06 07:24:16 UTC
Hm, perhaps it's related to Bug #9059.

Can you test 2.6.23-rc9 or the current Linus' tree, please?
Comment 10 Mike Harris 2007-10-09 21:00:14 UTC
I tried it with 2.6.23-rc9, and it is the same.
Comment 11 Rafael J. Wysocki 2007-12-12 16:38:24 UTC
Please install the current mainline kernel and check if the problem is present in it, thanks.
Comment 12 Zhang Rui 2008-11-19 22:57:33 UTC
hah, please attach the lspci output, please try 2.6.27 and see if the problem still exists.
Comment 13 ykzhao 2008-12-04 00:56:38 UTC
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?
Comment 14 ykzhao 2008-12-04 00:59:06 UTC
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.
Comment 15 ykzhao 2008-12-15 23:42:54 UTC
Ping Mike...
Comment 16 Mike Harris 2008-12-16 08:36:07 UTC
Still alive; just really busy. I hope to test the new kernel either tonight or 

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...
Comment 17 Shaohua 2008-12-23 22:26:36 UTC
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. 
Comment 18 Mike Harris 2008-12-24 13:21:17 UTC
Created attachment 19473 [details]
output of lspci
Comment 19 Mike Harris 2008-12-24 13:21:43 UTC
Just tested 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.
Comment 20 Mike Harris 2008-12-24 13:47:46 UTC
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?
Comment 21 Mike Harris 2008-12-24 13:48:51 UTC
Created attachment 19474 [details]
msg from "echo mem > /sys/power/state; dmesg > msg; sync" during successful suspend
Comment 22 ykzhao 2008-12-24 19:37:17 UTC
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.
Comment 23 ykzhao 2008-12-24 21:35:55 UTC
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

Comment 24 ykzhao 2009-02-11 21:55:23 UTC
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.

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