Re: hibernate, suspend and s2both support

Re: hibernate, suspend and s2both support

[Johannes Berg]

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

Re: hibernate, suspend and s2both support

[Tim Dijkstra]

On Sun, 18 Mar 2007 09:54:43 +0100
Johannes Berg <johannes@sipsolutions.net> wrote:

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

Thanks for the answers! I removed debian-powerpc from the cc-list as
you suggested.

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

So if I build a binary on ppc that first tries /dev/pmu (if it exists) and then
/sys/power/state, that would be safe? I guess that the powerpcs that do not
support suspend-to-ram will report that via the PMU_IOC_CAN_SLEEP ioctl and
they will lack 'mem' in /sys/power/state?

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

Hmm, so 'echo disk > /s/p/state' and s2ram suspend OK, but s2both doesn't?

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

Oops, Yes that was the wrong way around... That's what you get if you
don't have a Mac;) Did you try it with the obvious fix?

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

Yes you need an initramfs, but I don't see any reason why if
suspend-to-disk and suspend-to-ram work, s2both wouldn't. If we get
suspend-to-ram working I'll put up proper source package which you can
dpkg-buildpackage. That will include hooks for initramfs-tools and will
build an initramfs for you.

grts Tim

Re: hibernate, suspend and s2both support

[Johannes Berg]

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

On Sun, 2007-03-18 at 14:41 +0100, Tim Dijkstra wrote:

> So if I build a binary on ppc that first tries /dev/pmu (if it exists) and then
> /sys/power/state, that would be safe?

Yeah, my current patchset will print a message that the /dev/pmu ioctl
will be removed but that may well not be present.

> I guess that the powerpcs that do not
> support suspend-to-ram will report that via the PMU_IOC_CAN_SLEEP ioctl

They either have no /dev/pmu device or return an error on the ioctl.

>  and
> they will lack 'mem' in /sys/power/state?

That's tricky. Up until I posted a patch *very* recently (unreleased as
of yet I think) the contents of /sys/power/state didn't reflect what was
supported, in fact if *nothing* was supported then "mem" and "standby"
would be shown. Also, up until that patch I cited in my previous mail,
mem and standby would, on powermac, kill the machine. On other machines,
mem and standby exist but return an error.

> > 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.
> 
> Hmm, so 'echo disk > /s/p/state' and s2ram suspend OK, but s2both doesn't?

No, echo disk ... and s2ram both suspend ok, and I haven't tested your
s2both tool because I don't know what it does, it seemed to be a
userland suspend to disk for which I'd need special initramfs support. I
have tested the 'platform' powerdown method for suspend to disk support
in the kernel and that killed the machine due to a yet unidentified
problem.

> Oops, Yes that was the wrong way around... That's what you get if you
> don't have a Mac;) Did you try it with the obvious fix?

Yeah, it works and uses the pmu ioctl.

> Yes you need an initramfs, but I don't see any reason why if
> suspend-to-disk and suspend-to-ram work, s2both wouldn't. 

I think I wasn't really clear on what I said, see above.

> If we get
> suspend-to-ram working I'll put up proper source package which you can
> dpkg-buildpackage. That will include hooks for initramfs-tools and will
> build an initramfs for you.

Do you really think that I let debian build my initramfs? :P
Have you documented somewhere in text form what pm-utils needs in the
initramfs?

johannes

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

Re: hibernate, suspend and s2both support

[Tim Dijkstra]

On Sun, 18 Mar 2007 15:37:50 +0100
Johannes Berg <johannes@sipsolutions.net> wrote:

> On Sun, 2007-03-18 at 14:41 +0100, Tim Dijkstra wrote:
> 
> > So if I build a binary on ppc that first tries /dev/pmu (if it exists) and then
> > /sys/power/state, that would be safe?
> 
> Yeah, my current patchset will print a message that the /dev/pmu ioctl
> will be removed but that may well not be present.
> 
> > I guess that the powerpcs that do not
> > support suspend-to-ram will report that via the PMU_IOC_CAN_SLEEP ioctl
> 
> They either have no /dev/pmu device or return an error on the ioctl.
> 
> >  and
> > they will lack 'mem' in /sys/power/state?
> 
> That's tricky. Up until I posted a patch *very* recently (unreleased as
> of yet I think) the contents of /sys/power/state didn't reflect what was
> supported, in fact if *nothing* was supported then "mem" and "standby"
> would be shown. Also, up until that patch I cited in my previous mail,
> mem and standby would, on powermac, kill the machine. On other machines,
> mem and standby exist but return an error.

So maybe the safest algorithm would be
- If /dev/pmu exists
	- Check PMU_IOC_CAN_SLEEP
		- Yes -> suspend
		- No -> Fail (maybe prevents a crash when we would have tried 'echo mem')
- No /dev/pmu
	- try 'echo mem ...'


> have tested the 'platform' powerdown method for suspend to disk support
> in the kernel and that killed the machine due to a yet unidentified
> problem.

I think this is a know problem, at least it happens on more machines.
Will have to ask for the details.

> 
 > If we get
> > suspend-to-ram working I'll put up proper source package which you can
> > dpkg-buildpackage. That will include hooks for initramfs-tools and will
> > build an initramfs for you.
> 
> Do you really think that I let debian build my initramfs? :P
> Have you documented somewhere in text form what pm-utils needs in the
> initramfs?

Well before initramfs-tools I also crafted my own, but I got a bit fed
up about forgetting to update it when a new udev (or zzz) had arrived.

Anyway, on your initramfs you need /dev/snapshot, /sbin/resume and /etc/suspend.conf. 
Your swap partition needs to be available, your filesystems should _not_ be mounted
and then you should just call /sbin/resume.

Oh, I think I forgot to tell this before, but to use s2both/s2disk you
need a config file (if you build it from the tarball I send you it
is /etc/suspend.conf, on debian /etc/uswsusp.conf). In it you need at
least the line:

	resume device = <path to swap device node>

That is it.

grts Tim

Re: hibernate, suspend and s2both support

[Johannes Berg]

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

On Sun, 2007-03-18 at 23:46 +0100, Tim Dijkstra wrote:

> So maybe the safest algorithm would be
> - If /dev/pmu exists
> 	- Check PMU_IOC_CAN_SLEEP
> 		- Yes -> suspend
> 		- No -> Fail (maybe prevents a crash when we would have tried 'echo mem')

That's only when it returns 0/1, when calling it returns an error you
need to assume (for suspend) that /dev/pmu doesn't exist. If I can get
my plan through to deprecate both of the ioctls, that is.

> > have tested the 'platform' powerdown method for suspend to disk support
> > in the kernel and that killed the machine due to a yet unidentified
> > problem.
> 
> I think this is a know problem, at least it happens on more machines.
> Will have to ask for the details.

You can't even try to do it on powerpc right now afaik, and I am sure
that you can't do it after my patches. So you can't do anything wrong
either, though I'm still trying to figure out what I need to do to be
able to allow it.

johannes

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

Re: hibernate, suspend and s2both support

[Tim Dijkstra]

Hi,

I'm trying to get suspend-to-both (save state to disk, just like
hibernate, but then suspend to ram) to work on ppc.

In the end it is probably simpler than I imagined. Due to the work the
linux-pm guys did, it appears I only had to rip out all the evil hacks
some x86 machines need.

If someone could test the powerpc packages on debian by doing roughly
the following, that would be really nice:

a) Download:

http://www.famdijkstra.org/~tdykstra/debian/uswsusp/uswsusp_0.6~cvs20070202-2.diff.gz
http://www.famdijkstra.org/~tdykstra/debian/uswsusp/uswsusp_0.6~cvs20070202-2.dsc
http://www.famdijkstra.org/~tdykstra/debian/uswsusp/uswsusp_0.6~cvs20070202.orig.tar.gz

b) install debhelper (>= 5), pciutils-dev, docbook2x, po-debconf, libgcrypt-dev, zlib1g-dev, libsplashy0-dev

c) Unpack & Compile
$ dpkg-source -x uswsusp_0.6~cvs20070202-2.dsc
$ cd uswsusp-0.6~cvs20070202/
$ dpkg-buildpackage -us -uc -rfakeroot

d) Install
$ dpkg -i <the resulting deb>


The install process should update your initramfs if you use initramfs-tools.
You need an initramfs that includes the resume binary else it won't work.

For testing purposes it is best you don't have splashy installed or at least
disabled in /etc/uswsusp.conf.

Then run s2both. This should save to disk (you'll get some messages
reporting progress of that) and suspend-to-ram. Now wake up
your system.

If that went OK then run s2both and poweroff the hard way. Boot up again.

All this is of course on your own risk, but you knew that;)

As a bonus there is also a s2ram binary which won't do much more than
'echo mem > /sys/power/state' and ioctl(/dev/pmu,...) on older kernels.

grts Tim