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

[Sebastian Geiger <sbastig@gmx.net>]

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^)
>
>