[gentoo-amd64] Hibernate-ram

[gentoo-amd64] Hibernate-ram

[Sebastian Geiger]

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.

Best Regards

Re: [gentoo-amd64] Hibernate-ram

[Avuton Olrich]

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.
-- 
avuton
--
 "I've got a fever. And the only prescription is more cowbell." --
Christopher Walken

[gentoo-amd64] Re: Hibernate-ram

[Duncan]

"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

Re: [gentoo-amd64] Re: Hibernate-ram

[Sebastian Geiger]

Hi all,

I just rebooted with the old kernel and here "hibernate-ram" still 
works, the laptop also wakes up succcessfully. The Old Kernel is 
2.6.25-x something. The new one is 2.6.26 and here it doesnt work, also 
not if I switch to tty1 before. I have the latest bios update and i have 
all the latest updates.
So I conclude that the Problem is a bug in the Kernel. I will try and 
nail down the Problem a bit more clearly and then report back.

Best Regards
Sebastian

Duncan wrote:
> "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^)
>
>