[gentoo-amd64] Re: hibernate-ram not working

[Duncan]

Alex Schuster posted on Wed, 16 Jun 2010 18:21:41 +0200 as excerpted:

> Hi there!
>
> I already wrote about this on the gentoo-user list, but now that I'm on
> amd64 this list is more appropiate.
>
> Any idea why hibernate-ram is not working? It looks good at first, but
> when I resume, the display stays black. The numlock key ativates the
> LED, but I could not switch to a text console. After Alt-SysRq-R, caps
> and scroll lock flash, I guess that means kernel panic. Happened for the
> two times I tried. I see nothing in syslog.
>
> With my 32bit system (almost identical to this 64bit one), I never had a
> problem with this. I'm running tuxonice-sources-2.6.33-r2, and ati-
> drivers-10.5. Kernel .config is here:
> http://wonkology.org/~wonko/tmp/config-2.6.33-tuxonice-r2
>
> Suspend to disk works sometimes, but not always. But I asked about this
> on the TuxOnIce mailing list.

If someone had a definitive answer to that question, that worked for 
everyone, he'd have the thanks of very many users indeed!

First, a minor detour into definitions.  Formerly, in the Linux world it 
was "suspend-to-disk" and "suspend-to-ram".  However, AFAIK taking a hint 
from MS (which after all, a lot of new users are more familiar with than 
Linux), the community seems to have now agreed that the former "suspend-to-
disk" should be referred to as "hibernate", while "suspend-to-RAM" will 
continue to be referred to as "suspend".  IOW, "hibernate-ram" is a 
confusing term that shouldn't be used, as "hibernate" refers to the former 
"suspend-to-disk", while "suspend-ram" (or ultimately simply suspend, but 
it'll be quite some time before we get to that point, as it still refers 
to both at present) would refer to the RAM variant.  So "hibernate-ram" 
then becomes a contradiction in terms and is simply confusing.

So I assume you mean "suspend-to-ram", tho it really doesn't matter much 
for the suggestion below, which can be applied to both.

One thing that's mentioned in the various documentation that I've read 
(both suspend/hibernate and general kernel/X mode discussion, including 
discussion of KMS, where the simplicity of KMS is considered a major 
advantage over the previous setup), that applies here as it appears you're 
not yet doing the workaround below, is that the interplay between X's 
video drivers and the kernel is exceedingly complex.  As traditionally 
done, there's a very delicate dance between the kernel and X's userspace 
video drivers, with both effectively trying to control the same thing, and 
the possibility for all /sorts/ of race conditions and other such nasties 
to rear their ugly heads under various corner conditions on the various 
hardware -- and with suspend -- of both sorts -- being infamous for 
provoking exactly that sort of nasty.  Thankfully, with the reasonably new 
KMS (kernel mode switching) functionality, more of the functionality is 
now in the kernel, with X's user-mode simply telling the kernel what 
resolution and etc it wants and the kernel now handling it in nearly all 
cases, but as I said, that's quite new, and thus, subject to its own bugs, 
tho at least in theory they should be easier to deal with than the 
delicate race conditions and etc that the old interface had.

The suggestion is thus to switch out of X before invoking RAM-suspend or 
hibernate, in that way at least not mixing the complexities of suspend 
with the complexities of X mode graphics and the potential bugs there, 
because you're switching to the console before doing the suspend, and back 
to X only after the system has successfully returned from suspend.

So that's what I'd suggest.  At least for testing, you can simply switch 
to a text VT manually, before triggering the suspend (of whatever type).  
If that works, I think hibernate-script, the tux-on-ice solution I suspect 
you're using, has an option for that.

FWIW, I run my own custom script here.  It has a configurable "suspend-
VT", which I have configured to VT-11 (VT-12 being the logging VT, 1-6 
being text logins, and 7 being X, with VTs 8-10 still unused).  But until 
I added support for that, I was switching VTs manually, before triggering 
the script.  I run the script on both my netbook, where it gets a LOT of 
use in both disk and RAM modes, and on my main system, which I don't 
suspend that often.  But I've never run tux-on-ice, so I've never had the 
need to add support for that.

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