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
