Bug 42627

Created attachment 72187 [details]
Hibernate messages of 3.3.0 kernel

Excerpt of hibernate for 3.3.0 kernel. Hibernate was started on 09:06:50, see notebook was restarted at 09:10

Hibernation was also tested with kernels 3.2.0-rc6-49-g511585a-vanilla and 3.3.0-rc1-1-vanilla. There seems to be no great difference between 3.1.x and 3.2.x. The  3.3.0-rc1-1-vanilla however does not even turn of the power.

Re: unexpected for lid to wake from hibernate

please show the output from "cat /proc/acpi/wakeup"
if it shows the LID listed as enabled for wakeup from
S4, then lid should wake you up from S4 (hibernate).
You can disable that capability with this file too via
"echo LID > /proc/acpi/wakeup"

The other thing to try is alternate setting in
/sys/power/disk

"platform" here means ACPI S4
and "shutdown" means hard power-off of system.
One may work where the other does not.

Did hibernate on this system ever work under
any version of Linux?

output from "cat /proc/acpi/wakeup":
Device	S-state	  Status   Sysfs node
P0P1	  S4	*disabled  pci:0000:00:1e.0
GLAN	  S0	*disabled  
EHC1	  S3	*enabled   pci:0000:00:1d.0
EHC2	  S3	*enabled   pci:0000:00:1a.0
HDEF	  S3	*disabled  pci:0000:00:1b.0
RP01	  S5	*disabled  pci:0000:00:1c.0
PXSX	  S4	*disabled  
RP02	  S4	*disabled  pci:0000:00:1c.1
PXSX	  S4	*disabled  
NECU	  S3	*enabled   pci:0000:08:00.0
RP03	  S4	*disabled  
PXSX	  S4	*disabled  
RP04	  S4	*disabled  
PXSX	  S4	*disabled  
PXSX	  S4	*disabled  
PXS5	  S4	*disabled  
RP06	  S4	*disabled  pci:0000:00:1c.5
PXSX	  S4	*disabled  pci:0000:09:00.0
RP07	  S4	*disabled  pci:0000:00:1c.6
PXSX	  S4	*enabled   pci:0000:0a:00.0
RP08	  S4	*disabled  
PXSX	  S4	*disabled  
PEG0	  S4	*disabled  pci:0000:00:01.0
PEGP	  S4	*disabled  
PEG1	  S4	*disabled  
PEG2	  S4	*disabled  
PEG3	  S4	*disabled  
LID	  S5	*enabled   
   
output from "cat /sys/power/disk":
[platform] shutdown reboot

I do not think hibernate worked with any of the kernels I have tried (2.6.x, 3.0.x, 3.1.x, 3.2.x, 3.3.x). Sleep (suspend to ram) works with kernels 3.1.x and 3.2.x, but fails with kernel 3.3-rc1 (see Bug #42652).

Test with kernel 3.3.0-rc2 shows the same results as 3.2.x:
- Sleep (see Bug #42652) works again
- Hibernate (suspend to disk) does not work

Created attachment 72282 [details]
dmesg of restart after resume failed

The kernel (3.3.0-rc2) claims that
<7>[    1.877727] PM: Hibernation image not present or could not be loaded.
and
<6>[    3.055976] PM: Starting manual resume from disk
<7>[    3.063055] PM: Hibernation image partition 8:4 present
<7>[    3.063057] PM: Looking for hibernation image.
<7>[    3.063183] PM: Image not found (code -22)
<7>[    3.063184] PM: Hibernation image not present or could not be loaded.
although the image was written on hibernation and read on resume.

> The kernel (3.3.0-rc2) claims that
> <7>[    1.877727] PM: Hibernation image not present or could not be loaded.
> and
> <6>[    3.055976] PM: Starting manual resume from disk
> <7>[    3.063055] PM: Hibernation image partition 8:4 present
> <7>[    3.063057] PM: Looking for hibernation image.
> <7>[    3.063183] PM: Image not found (code -22)
> <7>[    3.063184] PM: Hibernation image not present or could not be loaded.
These log messages can be seen everytime you reboot a system.  So I guess you obtained the dmesg outputs after you restarted the machine that failed to hibernate.

You were using the opensuse s2disk utility to perform hibernation.  Could you please
1. tell me your default hibernation mode?
By executing 'cat /sys/power/disk', the one listed with brackets prompts you the default hibernation mode.
2. type the following commands instead of executing s2disk next time you try to hibernate?
# echo platform > /sys/power/disk
# echo disk > /sys/power/state

> although the image was written on hibernation and read on resume.
From comment#1, I can learn that your machine did not successfully hibernated.  Your final logs shows hibernation failed for USB devices.  Please remove all of your USB perihperals (especially your mouse) and try hibernation again to see whether the failure is caused by USB.

If you still face problems, you can test tow steps of hibernation by using pm_test interface:
1. test the freezing of processes
# echo freezer > /sys/power/pm_test
# echo platform > /sys/power/disk
# echo disk > /sys/power/state
2. test the freezing of processes and suspending of devices
# echo devices > /sys/power/pm_test
# echo platform > /sys/power/disk
# echo disk > /sys/power/state

You can return to normal mode from any of the pm_test modes by typing:
# echo none > /sys/power/pm_test

If "platform" does not work for you, you can try "reboot" mode by typing:
# echo reboot > /sys/power/disk
instead of
# echo platform > /sys/power/disk

Created attachment 73557 [details]
Hibernation test for kernle 3.4.1 with external USB devices

I have repeated the hibernation test with USB devices (external keyboard / mouse).
Storing image data and shutdown seen to work.
Also loading of image data seems to work (and is shown on the screen). 
Even processes seem to be started. Only the screen goes blank. So to me this looks more like a problem with the graphics driver.

Created attachment 73558 [details]
Test with kernel 3.4.1 without external USB devices

Again, hibernation seems to work. However, as in the case with attached external USB devices, the screen goes blank after loading of the image data.
It looks as if the nouveau driver makes a shutdown after loading of image data.

Created attachment 73559 [details]
Messages with freezer

When entering the commands	
echo freezer > /sys/power/pm_test
echo platform > /sys/power/disk
echo disk > /sys/power/state

Created attachment 73560 [details]
pm_test with devices

When entering the commands
 echo devices > /sys/power/pm_test
 echo platform > /sys/power/disk
 echo disk > /sys/power/state
as in the case of echo freezer > /sys/power/pm_test the system shortly shts dwon and then resumes.

If freezer/devices pm_test can work for your system, you might try to use "hardware" hibernation by:
 echo hardware > /sys/power/disk
 echo disk > /sys/power/state

You can also test every hibernation mode with the kernel setup parameter: "init=/bin/bash".

If you still face the same problem, since hibernation without external USB devices worked for your platform, let's confirm whether the problem is caused by a known EHCI bug for ultra reliable systems. If your system has a large scale external storages (I can learn this from your long period filesystem syncing logs) with fault-tolerant enabled, it might be the case you should be noted of the information included in the following mailing threads:
https://lkml.org/lkml/2007/10/29/443
https://lkml.org/lkml/2007/11/22/33
you can find more by searching google with keywords of "unload EHCI hibernation".  So could you please try to unload EHCI hcd before performing:
 echo [platform|hardware] > /sys/power/disk
 echo disk > /sys/power/state

If you still face the same problem after trying the workaround of uloading EHCI hcd before hibernation, there should be some nVidia guys helping you to figure out the true cause in your graphics driver.

(In reply to comment #12)
> 
> If you still face the same problem, since hibernation without external USB
> devices worked for your platform, let's confirm whether the problem is caused
> by a known EHCI bug for ultra reliable systems. 
Sorry, there is a misunderstanding. Hibernation seems to work, the problem is with the resume, and that is independent of whether there are external USB devices present or not.
> If your system has a large
> scale external storages (I can learn this from your long period filesystem
> syncing logs) with fault-tolerant enabled, it might be the case you should be
> noted of the information included in the following mailing threads:
> https://lkml.org/lkml/2007/10/29/443
> https://lkml.org/lkml/2007/11/22/33
The disk size is 625 GByte, of this ca. 8,7 GByte swap space and 252 GByte Linux partitions. Is this still considered large scale?
> you can find more by searching google with keywords of "unload EHCI
> hibernation".  So could you please try to unload EHCI hcd before performing:
>  echo [platform|hardware] > /sys/power/disk
>  echo disk > /sys/power/state
> 
> If you still face the same problem after trying the workaround of uloading
> EHCI
> hcd before hibernation, there should be some nVidia guys helping you to
> figure
> out the true cause in your graphics driver.
During the resume, even though the screen goes blank, some user processes still seem to resume. So I really think this is a problem with the graphics driver. More precisely how the resume interacts with the graphics driver, because using the nVidia native driver did not resolve the issue. Do you have an idea how to interest the persons working on the nouveau driver for the failing resume?

(In reply to comment #13)

Hi, let me first paste more comments on your attachments.

(In reply to comment #1)
> Created an attachment (id=72187) [details]
> Hibernate messages of 3.3.0 kernel
> 
> Excerpt of hibernate for 3.3.0 kernel. Hibernate was started on 09:06:50, see
> notebook was restarted at 09:10

I couldn't find anything showing a successful hibernation from this log.

After the message:
Jan 25 09:06:51 HATOSH kernel: [  986.045296] PM: Basic memory bitmaps created
I could not find any futher hibernation steps in this log.

If your machine restarted as what you've mentioned in comment #1, it should fail the hibernation before the filesystem syncing step...

So I guess there might be bugs around your external USB devices.

If it's not the cause, let us forget this log.

(In reply to comment #6)
> Created an attachment (id=72282) [details]
> dmesg of restart after resume failed
> 
> The kernel (3.3.0-rc2) claims that
> <7>[    1.877727] PM: Hibernation image not present or could not be loaded.
> and
> <6>[    3.055976] PM: Starting manual resume from disk
> <7>[    3.063055] PM: Hibernation image partition 8:4 present
> <7>[    3.063057] PM: Looking for hibernation image.
> <7>[    3.063183] PM: Image not found (code -22)
> <7>[    3.063184] PM: Hibernation image not present or could not be loaded.
> although the image was written on hibernation and read on resume.

These log messages can be seen everytime you reboot a system.  They are not failure indications, so let us forget this log.

(In reply to comment #10)
> Created an attachment (id=73559) [details]
> Messages with freezer
> 
> When entering the commands    
> echo freezer > /sys/power/pm_test
> echo platform > /sys/power/disk
> echo disk > /sys/power/state

From this messaage, I can see your system has successfully resumed from following messages:
Jun 11 10:56:05 HATOSH kernel: [ 1485.893314] PM: Basic memory bitmaps freed

There's also a userland resumed indication:
Jun 11 10:56:05 HATOSH acpid: 1 client rule loaded

It seems your system has passed the freezer test on "platform" hibernation mode.

(In reply to comment #11)
> Created an attachment (id=73560) [details]
> pm_test with devices
> 
> When entering the commands
>  echo devices > /sys/power/pm_test
>  echo platform > /sys/power/disk
>  echo disk > /sys/power/state
> as in the case of echo freezer > /sys/power/pm_test the system shortly shts
> dwon and then resumes.

From this messaage, I can see your system has successfully resumed from following messages:
Jun 11 10:59:43 HATOSH kernel: [ 1704.090586] PM: Basic memory bitmaps freed

There's also a userland resumed indication:
Jun 11 10:59:44 HATOSH acpid: 1 client rule loaded

It seems your system has passed the "devices" test on "platform" hibernation mode.

From the other attachments (id=72146), (id=73557), (id=73558), the system seems to be successfully resumed as what you've mentioned.  It might be a video card issue. 

If you pass the setup parameter "init=/bin/bash" to your kernel, you could probably see a successful resume.

Have you read the Documentation/power/video.txt?

You can try to pass "acpi_sleep=s3_bios" or "acpi_sleep=s3_mode" or "acpi_sleep=s3_bios,s3_mode" to see whether one of these workarounds can work for your platform.

You can also enter your BIOS configuration screen, tune the BIOS settings for your video card.

Wish any of these information can help.

hmmm,

can you remote login to this system after resume from hibernation?
if yes, please get the dmesg output after resume.

If no, please try
echo disk > /sys/power/state && sleep 30 && dmesg > ~/dmesg.out
to do a regular hibernation. If the hibernation is good, when you reboot next time, you should be able to find ~/dmesg,out and let's see if everything, especially the graphics driver, is going well.

Created attachment 74491 [details]
dmesg after resume

Output of 
"echo disk > /sys/power/state && sleep 50 && dmesg -r > /home/harald/Dokumente/dmesg.out &"
Note that the line
"[drm] nouveau 0000:01:00.0: 0x81C8: Condition still not met after 2000ms, skipping following opcodes"
appears also on normal startup and does not keep the graphics from working.
The screen goes black only after memory has been successfully restored.

(In reply to comment #21)
> Created an attachment (id=74491) [details]
> dmesg after resume
> Output of 
> "echo disk > /sys/power/state && sleep 50 && dmesg -r >
> /home/harald/Dokumente/dmesg.out &"
> Note that the line
> "[drm] nouveau 0000:01:00.0: 0x81C8: Condition still not met after 2000ms,
> skipping following opcodes"
> appears also on normal startup and does not keep the graphics from working.
> The screen goes black only after memory has been successfully restored.

<6>[  424.977027] [drm] nouveau 0000:01:00.0: Restoring GPU objects...
<6>[  425.101851] [drm] nouveau 0000:01:00.0: Reinitialising engines...
<6>[  425.102426] [drm] nouveau 0000:01:00.0: Restoring mode...
<3>[  427.118599] [drm] nouveau 0000:01:00.0: timeout: CURSOR_CTRL2_STATUS_ACTIVE(0)
<3>[  427.118668] [drm] nouveau 0000:01:00.0: CURSOR_CTRL2(0) = 0x00000000

but this is abnormal.
As everything goes well except the display, re-assign to the graphics experts.

Resume from hibernation also fails with kernel versions 3.5.4 and 3.6-rc6.

As suspend/resume bugs do not seem to be in focus of nouveau-developers I have decided to replace nouveau by the current nvidia driver (310.19). With this driver, both s2ram and s2disk work. Hopefully in the future also a working nouveau is available.
See also bug #45981

After installing openSuse 12.2 with kernel 3.4.11-2.16-desktop, resume from s2disk works with the nouveau driver. There is one (small) drawback compared to the nvidia driver: during resume, the notebook lid must remain open. With nvidia, the lid could be closed after pressing the power button.
I haven't tested s2disk on openSuse 12.2 with the 3.5.x and 3.6.x kernels.