[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-amd64
Subject:    [gentoo-amd64]  Re: Hibernate-ram
From:       Duncan <1i5t5.duncan () cox ! net>
Date:       2008-08-28 9:18:44
Message-ID: pan.2008.08.28.09.18.43 () cox ! net
[Download RAW message or body]

"Avuton Olrich" <avuton@gmail.com> posted
3aa654a40808271947v183adf76lc84264f945588171@mail.gmail.com, excerpted
below, on  Wed, 27 Aug 2008 19:47:45 -0700:

> On Wed, Aug 27, 2008 at 4:56 PM, Sebastian Geiger <sbastig@gmx.net>
> wrote:
>> I just upgraded to 2.6.26 and if I enter hibernate-ram the system
>> suspends but never wakes up again untill I do a cold reboot. Are there
>> any known issues currently with this Kernel version? I am using the
>> 2.6.26 tuxonice-sources and the latest hibernate script on amd64.
> 
> ACPI on linux is probably the most undependable things about the system.
> That being said, I've had much luck getting 'suspend to disk', aka
> hibernate, to work over 'suspend to ram', also known as sleep.
> 
> Best of luck, but suspend to ram working is like expecting all the
> planets to align with the sun. Each driver for each chip in your
> computer must be ready for it, or it's not happening.

... And the kernel devs will say the same thing.  They /are/ trying, and 
things /are/ generally improving gradually in that area, but it's well 
known that suspend to disk is /much/ more likely to work than suspend to 
RAM.

One thing you might try if you haven't already...  X and video drivers 
throw in a /lot/ more complexity.  Many people find that suspend (of 
either form) works MUCH better if they switch to a console before 
suspending (leaving X running).  If that works fine returning you to a 
console but switching back to X afterward does /not/ work, try shutting X 
down entirely before suspending.  That may work.

Beyond that, you can try unloading all non-critical modules and reloading 
them after you resume.

After you find a combination that works, you can of course script it, so 
it all happens automatically.

That said, if it was working with older kernels it'll be considered a 
regression and the kernel folks are likely to be very interested in it, 
particularly if you have time to file a kernel bug and do some follow-up 
for them as they ask you to.  I've had several bugs that I filed fixed, 
but then I usually start running the -rcs (or trying to run them, anyway) 
around -rc3 or so, and if I see a problem and it's not fixed by -rc4 or -
rc5, I'll bug it, and so far, they've always had it fixed before the full 
release version.  But it /can/ take rebuilding the kernel a few times, 
often with debug-logging patches applied so they can find out what's 
going on.  Another common techique is "bisecting", that is, taking the 
last known working version and the first known trouble version and 
testing an rc about in the middle, thus cutting the problem space in 
half, then one in the middle of that, etc, until you nail the bad rc, 
then doing the same thing with the daily snapshots between the last good 
rc and the first bad one, until you get the culprit day.  Often given the 
problem they can nail it once they know the day, but you can go farther 
if you want to using git to bisect the day's patches until you find the 
exact patch.  (Or, do as I sometimes do and bisect the kernel sources 
directory by directory and file by file until I find the file, then diff 
the files and narrow it down to a specific changed line or set of lines, 
tho that doesn't always work once you get beyond the file level since 
often the changes are dependent on one another.)

I may not be a coder, and I'm DEFINITELY not a kernel hacker, but I can 
file and help trace down bugs as I see 'em, thereby contributing my 
little bit to an improved Linux! =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


[prev in list] [next in list] [prev in thread] [next in thread]