Re: hibernate, suspend and s2both support

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 3459 bytes --]

Hi Tim,

Let me try to answer your questions, I've worked on suspend for powermac
machines for quite a while.

On Sun, 2007-03-18 at 01:00 +0100, Tim Dijkstra wrote:
> [please cc me]

You should have used linuxppc-dev instead of debian-powerpc but since
the thread is already here I'll just add them. Maybe take off
debian-powerpc when replying, people there can follow in the archives or
on linuxppc-dev. I just didn't want to take it out right away and leave
the thread floating.


> I'm the maintainer of uswsusp and pm-utils (which isn't in the archive
> yet). pm-utils will be used by hal/gnome-power-manager to suspend or
> hibernate. At the moment I'm looking at how to fold-in support for
> uswsusp, which can also do 's2both', which means writing the system
> state to disk before suspending to ram. Leaving you with the possibility
> to resume when you run out of batteries. To support that too for ppc I
> have some question about how hibernate/suspend is done on a ppc.

At this point you should start differentiating between powerpc (generic)
and powermac (Apple), although at the moment the only powerpc machine
that I'm aware of that can suspend to ram is 32-bit powermac in the
laptop form-factor.

> AFAIK, one can suspend-to-ram by using some ioctl's on the PMU. (Do all
> ppc's have a PMU? What about ppc64?)

Yes, although I have a patch series that I'm going to post soon that
deprecates the PMU ioctl and uses the regular mem > /sys/power/state
mechanism, in fact the PMU ioctl only invokes that exact same code.
However, you'll need to support older kernels, but trying
sys/power/state before PMU will be safe on any kernel released after May
25 2006 (commit 0fba3a1f39f8b0a50b56c8b068fa52131cbc84c2). Before that,
the machine just crashed when using the pm ops stuff and at the time I
hadn't understood yet why and just papered over the problem.

No 64-bit machines currently support suspend to ram at all, but I expect
that if we ever figure out how to wake up the nvidia video on some of
them we may support it, and it will then be via the /sys/power/state
mechanism.

> Hibernation can be done in the usual way. And s2both is unsupported. 

Yup; I've played with s2both a bit but it hangs the machine, I'm not
really sure why yet. It may be related to another slight bug I just
found yesterday though.

> Also s2ram doesn't need any quirks done to the graphics card, which is
> so often needed for x86 machines.

Yeah, although I think that's mostly because we don't allow s2ram on
machines where the regular graphics card is one that we don't know how
to wake up in the kernel...

> If this is all true, could someone try to build 's2ram' and 's2both'
> from the following tarball and run it? (no guarantees, on your own
> risk, etc;)
> 
> http://www.famdijkstra.org/~tdykstra/suspend_pmu.tar.bz2

It works on my machine (see above), but it doesn't use the PMU ioctl:

#ifndef CONFIG_PMU
        int fd;
        unsigned long arg = 0;

        if ((fd = open("/dev/pmu", O_RDWR)) < 0)
...

seems to be the wrong way around. A kernel-based suspend to both has no
chance of working properly since I currently disallow using 'platform'
for the disk poweroff state, but I intend to fix this if I can. I can't
try a userspace based s2both right now since I'd probably have to
rebuild my initramfs at least to test a power-failure during suspend.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]