en en en en en en ceb yue en en en en mk en hbs_lat es en en en en es en en en en en en en en en en en ru id en ro en en en en en en pt es en en en en en en en en en en en en ca en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en ceb yue en en en en mk en hbs_lat
Comment 1 Mike Harris 2007-09-15 15:42:29 UTC
Created attachment 12834 [details] output of acpidump
Comment 3 Rafael J. Wysocki 2007-09-16 12:26:00 UTC
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.
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? Thanks.
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. Thanks.
Comment 15 ykzhao 2008-12-15 23:42:54 UTC
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 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...
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 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.
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. thanks.
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 Thanks.
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. thanks.