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@×××××.com> posted
> 3aa654a40808271947v183adf76lc84264f945588171@××××××××××.com, excerpted
> below, on  Wed, 27 Aug 2008 19:47:45 -0700:
>
>
>> On Wed, Aug 27, 2008 at 4:56 PM, Sebastian Geiger <sbastig@×××.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^)
>
>