[gentoo-amd64] hibernate-ram not working

[gentoo-amd64] hibernate-ram not working

[Alex Schuster]

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.

	Wonko

[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

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

[Alex Schuster]

Duncan writes:

[a lot]

Duncan, many thanks for the quite detailed explanation! It is much 
appreciated.

I will do as suggested and switch to a text console before hibernating. I 
still don't understand why this should help, as the TuxOnIce user 
interface is in text mode anyway, but whatever. I tried hibernating (to 
disk) for another two times, and it worked just fine. Did not dare to 
try suspending (to RAM) yet.

This night I tried again. First attempt did not succeed, hald-addon-stor 
failed to freeze. I had this before, and just tried again. The next 
attempt _seemed_ to have worked, and the system powered down. But this 
morning it did not resume, it just bootet like if it was shut down 
regularly. 

Here is the syslog. Only two lines were logged for the last attempt? Or is 
this because the file system was not synced and the rest of the log did 
not get written to disk? If so, would there be some options for ext3 
journaling to make this work?
If not, I should try Henrik's idea of logging to the serial port.

Jun 18 02:15:41 [kernel]  hald-addon-stor (6464) failed to freeze.
Jun 18 02:15:41 [kernel] Restarting all filesystems ...
Jun 18 02:15:41 [kernel] Restarting tasks ... Restarting tasks ... done.
Jun 18 02:15:41 [kernel] TuxOnIce debugging info:
Jun 18 02:15:41 [kernel] - TuxOnIce core  : 3.1
Jun 18 02:15:41 [kernel] - Kernel Version : 2.6.33-tuxonice-r2
Jun 18 02:15:41 [kernel] - Compiler vers. : 4.4
Jun 18 02:15:41 [kernel] - Attempt number : 3
Jun 18 02:15:41 [kernel] - Parameters     : 17 667656 0 1 0 0
Jun 18 02:15:41 [kernel] - Overall expected compression percentage: 0.
Jun 18 02:15:41 [kernel] - Compressor is 'lzo'.
Jun 18 02:15:41 [kernel]   Compressed 3549491200 bytes into 1161791836 (67 
percent compression).
Jun 18 02:15:41 [kernel] - Block I/O active.
Jun 18 02:15:41 [kernel] - Max outstanding reads 1. Max writes 1367.
Jun 18 02:15:41 [kernel]   Memory_needed: 1024 x (4096 + 336 + 104) = 
4644864 bytes.
Jun 18 02:15:41 [kernel]   Free mem throttle point reached 0.
Jun 18 02:15:41 [kernel] - Swap Allocator enabled.
Jun 18 02:15:41 [kernel]   Swap available for image: 1048317 pages.
Jun 18 02:15:41 [kernel] - File Allocator active.
Jun 18 02:15:41 [kernel]   Storage available for image: 0 pages.
Jun 18 02:15:41 [kernel] - No I/O speed stats available.
Jun 18 02:15:41 [kernel] - Extra pages    : 4129 used/4629.
Jun 18 02:15:41 [kernel] - Result         : Hibernation was aborted.
Jun 18 02:15:41 [kernel]                  : Freezing filesystems and/or 
tasks failed.
Jun 18 02:15:50 [kernel] usb 1-5: reset high speed USB device using 
ehci_hcd and address 3
Jun 18 02:15:57 [kernel] TuxOnIce 3.1, with support for usm, compression, 
block i/o, swap storage, file storage, userui.
Jun 18 02:15:57 [kernel] Initiating a hibernation cycle.
Jun 18 11:07:43 [kernel] Linux version 2.6.33-tuxonice-r2 (root@noname) 
(gcc version 4.4.4 (Gentoo 4.4.4 p1.0) ) #2 SMP PREEMPT Mon Jun 14 
01:05:30 CEST 2010
Jun 18 11:07:43 [kernel] Command line: dolvm resume=swap:/dev/mapper/swap 
root=/dev/ram0 crypt_root=/dev/mapper/weird2-root 
real_root=/dev/mapper/root crypt_swap=/dev/weird2/swap swap_key=/etc/key 
swap_keydev=/dev/mapper/root

	Wonko

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

[Raffaele BELARDI]

Are you using gnome?  from gnome-power-manager-2.28.3.ebuild:

elog "To enable frequency scaling interface, use the following command:"
elog "  gconftool-2 /apps/gnome-power-manager/ui/cpufreq_show"
elog "Note that this will conflict with other power managment utility"
elog "like app-laptop/laptop-mode-tools."

I know I will have conflict because I am not currently using
gnome-power-manager for hibernation, but I have not installed it myself yet.

raf

Alex Schuster wrote:
> Duncan writes:
> 
> [a lot]
> 
> Duncan, many thanks for the quite detailed explanation! It is much 
> appreciated.
> 
> I will do as suggested and switch to a text console before hibernating. I 
> still don't understand why this should help, as the TuxOnIce user 
> interface is in text mode anyway, but whatever. I tried hibernating (to 
> disk) for another two times, and it worked just fine. Did not dare to 
> try suspending (to RAM) yet.
> 
> This night I tried again. First attempt did not succeed, hald-addon-stor 
> failed to freeze. I had this before, and just tried again. The next 
> attempt _seemed_ to have worked, and the system powered down. But this 
> morning it did not resume, it just bootet like if it was shut down 
> regularly. 
> 
> Here is the syslog. Only two lines were logged for the last attempt? Or is 
> this because the file system was not synced and the rest of the log did 
> not get written to disk? If so, would there be some options for ext3 
> journaling to make this work?
> If not, I should try Henrik's idea of logging to the serial port.
> 
> Jun 18 02:15:41 [kernel]  hald-addon-stor (6464) failed to freeze.
> Jun 18 02:15:41 [kernel] Restarting all filesystems ...
> Jun 18 02:15:41 [kernel] Restarting tasks ... Restarting tasks ... done.
> Jun 18 02:15:41 [kernel] TuxOnIce debugging info:
> Jun 18 02:15:41 [kernel] - TuxOnIce core  : 3.1
> Jun 18 02:15:41 [kernel] - Kernel Version : 2.6.33-tuxonice-r2
> Jun 18 02:15:41 [kernel] - Compiler vers. : 4.4
> Jun 18 02:15:41 [kernel] - Attempt number : 3
> Jun 18 02:15:41 [kernel] - Parameters     : 17 667656 0 1 0 0
> Jun 18 02:15:41 [kernel] - Overall expected compression percentage: 0.
> Jun 18 02:15:41 [kernel] - Compressor is 'lzo'.
> Jun 18 02:15:41 [kernel]   Compressed 3549491200 bytes into 1161791836 (67 
> percent compression).
> Jun 18 02:15:41 [kernel] - Block I/O active.
> Jun 18 02:15:41 [kernel] - Max outstanding reads 1. Max writes 1367.
> Jun 18 02:15:41 [kernel]   Memory_needed: 1024 x (4096 + 336 + 104) = 
> 4644864 bytes.
> Jun 18 02:15:41 [kernel]   Free mem throttle point reached 0.
> Jun 18 02:15:41 [kernel] - Swap Allocator enabled.
> Jun 18 02:15:41 [kernel]   Swap available for image: 1048317 pages.
> Jun 18 02:15:41 [kernel] - File Allocator active.
> Jun 18 02:15:41 [kernel]   Storage available for image: 0 pages.
> Jun 18 02:15:41 [kernel] - No I/O speed stats available.
> Jun 18 02:15:41 [kernel] - Extra pages    : 4129 used/4629.
> Jun 18 02:15:41 [kernel] - Result         : Hibernation was aborted.
> Jun 18 02:15:41 [kernel]                  : Freezing filesystems and/or 
> tasks failed.
> Jun 18 02:15:50 [kernel] usb 1-5: reset high speed USB device using 
> ehci_hcd and address 3
> Jun 18 02:15:57 [kernel] TuxOnIce 3.1, with support for usm, compression, 
> block i/o, swap storage, file storage, userui.
> Jun 18 02:15:57 [kernel] Initiating a hibernation cycle.
> Jun 18 11:07:43 [kernel] Linux version 2.6.33-tuxonice-r2 (root@noname) 
> (gcc version 4.4.4 (Gentoo 4.4.4 p1.0) ) #2 SMP PREEMPT Mon Jun 14 
> 01:05:30 CEST 2010
> Jun 18 11:07:43 [kernel] Command line: dolvm resume=swap:/dev/mapper/swap 
> root=/dev/ram0 crypt_root=/dev/mapper/weird2-root 
> real_root=/dev/mapper/root crypt_swap=/dev/weird2/swap swap_key=/etc/key 
> swap_keydev=/dev/mapper/root
> 
> 	Wonko
> 
> 

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

[Alex Schuster]

Raffaele BELARDI writes:

> Are you using gnome?  from gnome-power-manager-2.28.3.ebuild:

No, KDE4, without any power mnagement applets. I hibernate from the 
command line in a text console.

	Wonko

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

[Henrik Ala-Uotila]

Hi,

On Wed, 2010-06-16 at 18:21 +0200, Alex Schuster wrote:
> 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.

Perhaps kernel messages would help you diagnose the problem. By
supplying the "console=" kernel parameter you can get kernel messages
over (say) a serial port or USB.

 - Henrik

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

[Alex Schuster]

Henrik Ala-Uotila writes:

> Perhaps kernel messages would help you diagnose the problem. By
> supplying the "console=" kernel parameter you can get kernel messages
> over (say) a serial port or USB.

Good idea, thanks. I'll have a look into that.

	Wonko

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

[Peter Volkov]

В Срд, 16/06/2010 в 18:21 +0200, Alex Schuster пишет:
> Any idea why hibernate-ram is not working? 

> I'm running tuxonice-sources-2.6.33-r2, and ati-drivers-10.5.

Another options to try:

1. upgrade bios. Suspend to RAM is known to be more sensitive to bios
compared with suspend-to-disk.

2. Try in-vanila-kernel suspend-to-ram. Personally I use it without
problems on all notebooks around.

-- 
Peter.