http://bugzilla.opensuse.org/show_bug.cgi?id=917221 --- Comment #13 from John Leys <wguy4biz@comcast.net> --- The problem happens pretty much universally now when using pm-hibernate; i have not had a successful resume in some time using pm-hibernate. The pm-suspend works fine. In doing some research, i discovered that a way to test is to write directly to files in the /sys/power directory. When i do this, the hibernate works every time: 1. echo "platform" > /sys/power/disk 2. echo "disk" /sys/power/state The hibernate/thaw works correctly and there does not seem to be any problem finding the snapshotted image on the disk used for resume. The number of the disk used for snapshotting and restoring is the one stored in /sys/power/resume file, and is 8:5, reflecting the number for the resume disk, /dev/sda5: # ll /dev/sda5 brw-rw---- 1 root disk 8, 5 Feb 18 16:19 /dev/sda5 It is not clear whether s2disk is the problem, but i tried both 'uswsusp' and 'kernel' methods for hibernate, changing SLEEP_MODULE in /usr/lib/pm-utils/defaults, but neither seemed to work; both end up not being able to find the hibernation image. While it is difficult to say with certainty because the log messages roll by so quickly during the boot/resume processing, it appeared to me as if the messages in the failed resume case looked more like the boot messages, with some resume messages thrown in, than the successful resume messages. In the case of the successful resume, i did not see any messages like the following, though these do show up during boot processing: Feb 18 16:19:38 linux-ky6z kernel: [TTM] Initializing pool allocator Feb 18 16:19:38 linux-ky6z kernel: [TTM] Initializing DMA pool allocator Feb 18 16:19:38 linux-ky6z kernel: nouveau [ DRM] VRAM: 1024 MiB Feb 18 16:19:38 linux-ky6z kernel: nouveau [ DRM] GART: 1048576 MiB It may be that the reason why i did not see these in the successful resume is that these msgs flew by during the resume, but there seems to be a console clear just before these msgs are printed to the console and there is also a console clear just before the successful resume gets to the point where it is restoring the image; the msgs prior to the clear seem to be the same in both cases, though it is exceedingly difficult to tell for certain. I strongly suspect that these are not present during the successful resume, however, because i think that they would show up in the journal once it comes online. The following lines are in the journal of the successful resume: Feb 18 16:03:28 linux-ky6z kernel: ACPI: Waking up from system sleep state S4 Feb 18 16:03:28 linux-ky6z kernel: PM: noirq restore of devices complete after 11.515 msecs Feb 18 16:03:28 linux-ky6z kernel: PM: early restore of devices complete after 0.767 msecs Feb 18 16:03:28 linux-ky6z kernel: nouveau [ DRM] re-enabling device... Feb 18 16:03:28 linux-ky6z kernel: nouveau [ DRM] resuming kernel object tree... ... Feb 18 16:03:28 linux-ky6z kernel: nouveau [ CLK][0000:01:00.0] --: core 405 MHz shader 810 MHz memory 405 MHz Feb 18 16:03:28 linux-ky6z kernel: nouveau [ DRM] resuming client object trees... Feb 18 16:03:28 linux-ky6z kernel: nouveau [ DRM] resuming display... Feb 18 16:03:28 linux-ky6z kernel: nouveau [ DRM] resuming console... The nouveau lines in the failed resume look like the device is being initialized whereas the nouveau lines in the successful resume appear to be for a device that is resuming from suspension. -- You are receiving this mail because: You are on the CC list for the bug.