Created attachment 72146 [details] Excerpt of the messages. Hibernation was called on 17:51:10, the lid was opened around 17:53:40 Environment: Hardware: Toshiba Satellite L755-161 notebook System: openSuse 12.1 Kernel: 3.1.0-1.2 Symptoms: When hibernation of the system is called, the memory seems to be saved to disk and after some time the system seems to be shutdown. However, on opening the lid the system restarts. This is unexpected (to end hibernation, I would expect pressing the power button to be necessary). Then, after approximately 36 sec, the screen goes dark. To get the system running, a hard shutdown via power button must first be made. The message seem to show that the shutdown is completed only after the lid of the notebook is opened.
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.