Most recent kernel where this bug did *NOT* occur: possibly 2.6.20 (not sure) Distribution: Debian, vanilla kernel Hardware Environment: Thinkpad R60, Intel Core 2 Duo, 1 Gb RAM Software Environment: x86_64 SMP kernel, Debian sid, XFS partitions. Problem Description: Hibernating with s2disk doesn't work reliably. Sometimes it reboots or powers off while writing the image to disk (before completing). Sometimes it hangs before starting to write the image. I think it fails more often when there are more programs loaded. When I test from single-user mode, or from X11 with no apps running, it usually works. But when I try to hibernate during normal use (with some Emacs windows, konsole sessions, a mail program and some web browser windows open) it seems to fail every time. "s2ram" works well though. Steps to reproduce: Issue s2disk from an X session with a normal workload. I'm not sure how to reproduce it reliably.
Does it happen in every mode of hibernation or in the 'platform' mode only?
No, I just tried ~# echo shutdown > /sys/power/disk ~# s2disk and it shut down after writing 80% of the image. This is now on kernel 2.6.22-rc4 with uswsusp 0.3~cvs20060928-7 (Debian).
s2disk doesn't use the interface in /sys/power . You need to edit the s2disk's configuration file (usually /etc/suspend.conf). Besides, are you able to test the built-in swsusp in the 'shutdown' mode?
Ok, I just tried it with "shutdown method = shutdown" in /etc/uswsusp.conf (apparently the config file location in Debian). It shut down while writing the image, as before.
Created attachment 11705 [details] My kernel configuration This is my kernel config for 2.6.22-rc4.
Is your root partition an XFS one?
> Is your root partition an XFS one? No, it's actually ext3, but all my other partitions are XFS.
Could you please boot with init=/bin/bash, unmount all of the nonroot filesystems, mount /sys and /proc, and try to hibernate with 'echo shutdown = /sys/power/disk && echo disk > /sys/power/state' ?
Sorry, there's a typo in my previous message. Should be: 'echo shutdown > /sys/power/disk && echo disk > /sys/power/state'
Subject: Re: hibernation broken in recent kernels > Could you please boot with init=/bin/bash, unmount all of the > nonroot filesystems, mount /sys and /proc, and try to hibernate Yes, it works. Tried about eight times in a row. Marcus
Could you, additionally, after booting with init=/bin/bash and mounting the /proc and /sys filesystems, load the same set of modules that are normally loaded on the fully functional system and then try to hibernate? I'd like to make sure that none of the modules causes the problem to appear.
Subject: Re: hibernation broken in recent kernels > Could you, additionally, after booting with init=/bin/bash and mounting the > /proc and /sys filesystems, load the same set of modules that are normally > loaded on the fully functional system and then try to hibernate? Yes, tried it 10 times in a row, and it works. Marcus
Why are my comments listed as coming from "Guillermo Marcus"? I sent those by replying by e-mail! Anyway I am now on 2.6.22-rc6 and the problem remains.
Is there any solution on the horizon? Do you think it has to do with XFS? Should I perhaps try with init=/bin/bash and only mount one XFS file system? Marcus
(In reply to comment #14) > Is there any solution on the horizon? No. > Do you think it has to do with XFS? Not directly, but XFS seems to expose the problem. It seems that ReiserFS does that too, but quite differently. > Should I perhaps try with init=/bin/bash and only mount one XFS file system? Yes, please. Do you have laptop mode enabled by chance?
> > Should I perhaps try with init=/bin/bash and only mount one XFS file > system? > > Yes, please. That didn't trigger it, but in this case the hibernate is almost instantaneous since almost nothing is running, so I'm not sure it means anything. > Do you have laptop mode enabled by chance? No. Marcus
(In reply to comment #16) > > > Should I perhaps try with init=/bin/bash and only mount one XFS file > system? > > > > Yes, please. > > That didn't trigger it, but in this case the hibernate is almost > instantaneous > since almost nothing is running, so I'm not sure it means anything. Well, you may continue these experiments with enabling more and more things before the hibernation to see at which point it will start to fail ... > > Do you have laptop mode enabled by chance? > > No. Good. One suspect less. ;-) Rafael
(In reply to comment #17) > Well, you may continue these experiments with enabling more and more things > before the hibernation to see at which point it will start to fail ... Ok. So far I know it fails if kdm is started, even without logging in. By then all sorts of daemons are running. Marcus
It seems to work if kdm is stopped (thus no X session running), even with all the other daemons active. Could this have to do with X, or is it just the memory usage?
I don't know. It may be related to the way in which the X server handles the graphics hardware.
The bug happens with 2.6.22 final as well. I observed that the shutdown seems to happen exactly after writing 89% of the image. The numbers displayed during hibernate are (hand-copied, units missing): Image size 278192 Free swap 957952 Saving 69547 image data pages
I have a different computer, but since kernel 2.6.21+ I also have a suspend regression , Now I am trying a kernel 2.6.22 and after wakeup the system became slow, quite slow, not much but I see a difference . And I all see on dmesg some messages like this: psmouse.c: TouchPad at isa0060/serio4/input0 lost synchronization, throwing 1 bytes away. if I back to a kernel 2.6.20, hibernate computer more than ten times without problems
I also have a slowdown of the timer: after reboot and start ntpd I had: Jul 28 02:49:56 localhost ntpd[3081]: frequency initialized 0.000 PPM from /var/lib/ntp/drift Jul 28 02:49:56 localhost ntpd[3081]: synchronized to 194.100.206.70, stratum 2 Jul 28 03:05:37 localhost ntpd[3081]: time reset +4045.288170 s Jul 28 03:05:37 localhost ntpd[3081]: kernel time sync status change 0001 Jul 28 03:10:20 localhost ntpd[3081]: synchronized to 192.36.143.151, stratum 1
Do you have NO_HZ set in the kernel configuration?
Confirmed the original problem with 2.6.23-rc1.
Can you post your current .config, please?
Created attachment 12796 [details] Kernel config for 2.6.23-rc3 This config is for a kernel built from the wireless-dev tree based on 2.6.23-rc3.
Can you try to hibernate using the kernel built-in code, by doing: # echo disk > /sys/power/state from X terminal with typical workload?
(In reply to comment #28) > Can you try to hibernate using the kernel built-in code, by doing: > > # echo disk > /sys/power/state > > from X terminal with typical workload? > no "big" differences
There are some important suspend/hibernation related fixes in the current Linus' tree. Can you please test 2.6.23-rc9?
kernel 2.6.23-rc9-git1.fc8 seems that resolve my problems with hibernation; Thanks !
OK, so I'm closing this bug. Please reopen if necessary.
It still doesn't work for me, so I'm reopening (and I don't think Sérgio's problem is very similar to mine). With 2.6.23-rc9 from wireless-2.6 tree it hangs at "Suspending consoles" with the suspend LED blinking. However it succeeded when I tried from single-user mode. Will try to do some more testing with 2.6.23. Is there anything that can be done to debug it more efficiently?
Hibernation succeeds if I stop X11 first. Tested on 2.6.23 (Linus git as of yesterday). This seems to be the general pattern: If X is running, it doesn't work. I have an Intel graphics chipset.
(In reply to comment #33) > It still doesn't work for me, so I'm reopening (and I don't think Sérgio's > problem is very similar to mine). could be similar , we just use different software , I use Ferdora kernels, and different X.org , I am using Xserver 1.4.1 branch (In reply to comment #34) > Hibernation succeeds if I stop X11 first. Tested on 2.6.23 (Linus git as of > yesterday). This seems to be the general pattern: If X is running, it doesn't > work. > > I have an Intel graphics chipset. > I also have a Intel graphics chipset ( intel 915GM ) after resume with X, can you back to console (crtl+alt+f1) and return to X (crtl+alt+f7) ? On kernel 2.6.23 I had a problem with backlight or blacklight , lid button doesn't work ! If I boot computer and close lid (to plug other devices like mouse and network), after a little while when I open lid, I can't get screen anymore , I have to reboot my laptop to have screen. on suspend and resume I have to go to console and return to X go get screen maybe I will open other bug to ACPI
This appears to be fixed now (2.6.24-rc7). Closing.
That was too quick apparently. It still sometimes shuts down while writing the image, with 2.6.24.
hmmm, does the problem still exist in the latest kernel release, say 2.6.27?
As there is no response for nearly three months, how about close this bug? Thanks.
close it as there is no response for more than 2 months.