standby to disk transition

standby to disk transition

[Victor Porton,,,]

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

There should be something such which would cause (after user
specified timeout, e.g. a hour) automatically switch the
system from standby to suspend to disk (or suspend to mem).

Probably to make this transition possible without turning HDD
on, there should be a hibrid of standby and suspend to disk:
do suspend to disk but then enter standby instead of shutting
down. This state should be (dependently on whether there was
user input during the timeout) like standby in quick exit from
it and be like suspend to disk in regard that then computer
could be turned off (manually by power button or by timeout).

Do you understand the idea? For me curently standby is useless
as it even does not turn off the fans and computer continues
to produce noise when in standby. Suspend to disk is also not
quite good for me because it takes 40 sec to take it out.
I want the state when computer enters standby automatically
saving state to disk before standby and then if no user input
by timeout either enters real suspend to disk, or if I wake it
exits from this state quickly.

Or as a possible alternative, we could suspend SIMULTANEOUSLY
to disk and to mem (with switching into suspend-to-disk by
timeout), to have both quick restoration and automatically
fully turning it off.

I realize that it may be hard to design and implement, but my
idea is very nice and convenient for users. So it would be
great if you will do it to Linux 2.8...

(To implement switching from standby to an other mode, we
probably can use BIOS wake timer feature. Or for me it would
be currently acceptable if standby would turn off only HDD
instead of real standby so that during standby processor timer
could continue to function.)

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: standby to disk transition

[Pavel Machek]

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

On Po 13-03-06 07:34:36, Victor Porton,,, wrote:
> There should be something such which would cause (after user
> specified timeout, e.g. a hour) automatically switch the
> system from standby to suspend to disk (or suspend to mem).
....
> Or as a possible alternative, we could suspend SIMULTANEOUSLY
> to disk and to mem (with switching into suspend-to-disk by
> timeout), to have both quick restoration and automatically
> fully turning it off.

Yep, it would be nice.

Does that mean you are working on it and will send me a patch? Do you
want help coding?
							Pavel
-- 
105:        bool bUnix = Environment.OSVersion.ToString().IndexOf( "Unix" ) != -1;

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Adam Belay]

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

On Mon, Mar 13, 2006 at 09:30:38AM +0100, Pavel Machek wrote:
> On Po 13-03-06 07:34:36, Victor Porton,,, wrote:
> > There should be something such which would cause (after user
> > specified timeout, e.g. a hour) automatically switch the
> > system from standby to suspend to disk (or suspend to mem).
> ....
> > Or as a possible alternative, we could suspend SIMULTANEOUSLY
> > to disk and to mem (with switching into suspend-to-disk by
> > timeout), to have both quick restoration and automatically
> > fully turning it off.
> 
> Yep, it would be nice.
> 
> Does that mean you are working on it and will send me a patch? Do you
> want help coding?
> 							Pavel

The simultaneous idea sounds very similar to the idea Nigel had around a year
ago.  It may have been implemented to some degree.

The timeout feature could be done using the ACPI alarm interface, but there's
no reliable way of knowing how long the system can remain in a suspend state
on the x86 mobile platform, so waking up at the right time would be tricky if
not impossible.

Thanks,
Adam

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Pavel Machek]

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

On Po 13-03-06 03:48:11, Adam Belay wrote:
> On Mon, Mar 13, 2006 at 09:30:38AM +0100, Pavel Machek wrote:
> > On Po 13-03-06 07:34:36, Victor Porton,,, wrote:
> > > There should be something such which would cause (after user
> > > specified timeout, e.g. a hour) automatically switch the
> > > system from standby to suspend to disk (or suspend to mem).
> > ....
> > > Or as a possible alternative, we could suspend SIMULTANEOUSLY
> > > to disk and to mem (with switching into suspend-to-disk by
> > > timeout), to have both quick restoration and automatically
> > > fully turning it off.
> > 
> > Yep, it would be nice.
> > 
> > Does that mean you are working on it and will send me a patch? Do you
> > want help coding?
> 
> The simultaneous idea sounds very similar to the idea Nigel had around a year
> ago.  It may have been implemented to some degree.

suspend2 probably supports it. (Of course; suspend2 supports
everything :-).

> The timeout feature could be done using the ACPI alarm interface, but there's
> no reliable way of knowing how long the system can remain in a suspend state
> on the x86 mobile platform, so waking up at the right time would be tricky if
> not impossible.

Make it an hour... System should be able to stay suspended for an
hour. IIRC Apple did something like this? I'd just be slightly worried
about machine waking up itself just when you hit the turbulence in the
airplane, or something like that. 
								Pavel
-- 
108:

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Adam Belay]

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

On Mon, Mar 13, 2006 at 09:50:42AM +0100, Pavel Machek wrote:
> On Po 13-03-06 03:48:11, Adam Belay wrote:
> > The timeout feature could be done using the ACPI alarm interface, but there's
> > no reliable way of knowing how long the system can remain in a suspend state
> > on the x86 mobile platform, so waking up at the right time would be tricky if
> > not impossible.
> 
> Make it an hour... System should be able to stay suspended for an
> hour. IIRC Apple did something like this? I'd just be slightly worried
> about machine waking up itself just when you hit the turbulence in the
> airplane, or something like that. 

Hmm, but let's say the battery is 40% charged.  Then it's not very clear if it
will last an hour.  All of a sudden the issue becomes system specific, or it
may even depend on things like whether wake-on-lan is enabled, right?

If we could get a power management event and wake the system when the battery
reaches a low condition that would be really awesome.  But I don't think this
is possible AFAIK.

Thanks,
Adam

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Pavel Machek]

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

On Po 13-03-06 04:07:59, Adam Belay wrote:
> On Mon, Mar 13, 2006 at 09:50:42AM +0100, Pavel Machek wrote:
> > On Po 13-03-06 03:48:11, Adam Belay wrote:
> > > The timeout feature could be done using the ACPI alarm interface, but there's
> > > no reliable way of knowing how long the system can remain in a suspend state
> > > on the x86 mobile platform, so waking up at the right time would be tricky if
> > > not impossible.
> > 
> > Make it an hour... System should be able to stay suspended for an
> > hour. IIRC Apple did something like this? I'd just be slightly worried
> > about machine waking up itself just when you hit the turbulence in the
> > airplane, or something like that. 
> 
> Hmm, but let's say the battery is 40% charged.  Then it's not very clear if it
> will last an hour.  All of a sudden the issue becomes system specific, or it
> may even depend on things like whether wake-on-lan is enabled,
>right?

40% battery should still last 10+ hours in suspend-to-RAM, unless
something is wrong.

You *could* wakeup every minute or so to check the battery state; some
PDAs actually do that.

> If we could get a power management event and wake the system when the battery
> reaches a low condition that would be really awesome.  But I don't think this
> is possible AFAIK.

ACPI people have to comments, but see above, it can be emulated by
polling.
								Pavel

-- 
166:

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Nigel Cunningham]

[-- Attachment #1.1: Type: text/plain, Size: 1714 bytes --]

Hi.

On Monday 13 March 2006 18:48, Adam Belay wrote:
> On Mon, Mar 13, 2006 at 09:30:38AM +0100, Pavel Machek wrote:
> > On Po 13-03-06 07:34:36, Victor Porton,,, wrote:
> > > There should be something such which would cause (after user
> > > specified timeout, e.g. a hour) automatically switch the
> > > system from standby to suspend to disk (or suspend to mem).
> >
> > ....
> >
> > > Or as a possible alternative, we could suspend SIMULTANEOUSLY
> > > to disk and to mem (with switching into suspend-to-disk by
> > > timeout), to have both quick restoration and automatically
> > > fully turning it off.
> >
> > Yep, it would be nice.
> >
> > Does that mean you are working on it and will send me a patch? Do you
> > want help coding?
> > 							Pavel
>
> The simultaneous idea sounds very similar to the idea Nigel had around a
> year ago.  It may have been implemented to some degree.

Yes, it's been implemented for ages, and works fine.

> The timeout feature could be done using the ACPI alarm interface, but
> there's no reliable way of knowing how long the system can remain in a
> suspend state on the x86 mobile platform, so waking up at the right time
> would be tricky if not impossible.

I'd like this too. I think, though, that the interval should be configurable. 
No one knows how long a battery will last better than the person who owns the 
laptop and has learnt from experience that on this computer 4% is where the 
computer switches off but on the other computer, you can run it down to 2%.

Regards,

Nigel
-- 
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net                IRC: #suspend2 on Freenode

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Dave Jones]

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

On Mon, Mar 13, 2006 at 10:13:32AM +0100, Pavel Machek wrote:
 > On Po 13-03-06 04:07:59, Adam Belay wrote:
 > > On Mon, Mar 13, 2006 at 09:50:42AM +0100, Pavel Machek wrote:
 > > > On Po 13-03-06 03:48:11, Adam Belay wrote:
 > > > > The timeout feature could be done using the ACPI alarm interface, but there's
 > > > > no reliable way of knowing how long the system can remain in a suspend state
 > > > > on the x86 mobile platform, so waking up at the right time would be tricky if
 > > > > not impossible.
 > > > 
 > > > Make it an hour... System should be able to stay suspended for an
 > > > hour. IIRC Apple did something like this? I'd just be slightly worried
 > > > about machine waking up itself just when you hit the turbulence in the
 > > > airplane, or something like that. 
 > > 
 > > Hmm, but let's say the battery is 40% charged.  Then it's not very clear if it
 > > will last an hour.  All of a sudden the issue becomes system specific, or it
 > > may even depend on things like whether wake-on-lan is enabled,
 > >right?
 > 
 > 40% battery should still last 10+ hours in suspend-to-RAM, unless
 > something is wrong.
 > 
 > You *could* wakeup every minute or so to check the battery state; some
 > PDAs actually do that.

if suspend-to-disk is fast enough, you could just *always* write
to disk, even if we're doing S3.  If power runs out, you then have a
valid resume image on-disk.  iirc, this is what Windows does.

		Dave

-- 
http://www.codemonkey.org.uk

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Pavel Machek]

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

On Po 13-03-06 13:33:18, Dave Jones wrote:
> On Mon, Mar 13, 2006 at 10:13:32AM +0100, Pavel Machek wrote:
>  > On Po 13-03-06 04:07:59, Adam Belay wrote:
>  > > On Mon, Mar 13, 2006 at 09:50:42AM +0100, Pavel Machek wrote:
>  > > > On Po 13-03-06 03:48:11, Adam Belay wrote:
>  > > > > The timeout feature could be done using the ACPI alarm interface, but there's
>  > > > > no reliable way of knowing how long the system can remain in a suspend state
>  > > > > on the x86 mobile platform, so waking up at the right time would be tricky if
>  > > > > not impossible.
>  > > > 
>  > > > Make it an hour... System should be able to stay suspended for an
>  > > > hour. IIRC Apple did something like this? I'd just be slightly worried
>  > > > about machine waking up itself just when you hit the turbulence in the
>  > > > airplane, or something like that. 
>  > > 
>  > > Hmm, but let's say the battery is 40% charged.  Then it's not very clear if it
>  > > will last an hour.  All of a sudden the issue becomes system specific, or it
>  > > may even depend on things like whether wake-on-lan is enabled,
>  > >right?
>  > 
>  > 40% battery should still last 10+ hours in suspend-to-RAM, unless
>  > something is wrong.
>  > 
>  > You *could* wakeup every minute or so to check the battery state; some
>  > PDAs actually do that.
> 
> if suspend-to-disk is fast enough, you could just *always* write
> to disk, even if we're doing S3.  If power runs out, you then have a
> valid resume image on-disk.  iirc, this is what Windows does.

Yep, I call that suspend-to-both. It is planned, but not really
trivial, and I'm a little busy. If someone wants to help....
								Pavel
-- 
123:    {

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Dave Jones]

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

On Mon, Mar 13, 2006 at 10:24:20PM +0100, Pavel Machek wrote:

 > > if suspend-to-disk is fast enough, you could just *always* write
 > > to disk, even if we're doing S3.  If power runs out, you then have a
 > > valid resume image on-disk.  iirc, this is what Windows does.
 > 
 > Yep, I call that suspend-to-both. It is planned, but not really
 > trivial, and I'm a little busy. If someone wants to help....

I was thinking a few days ago. With your move of all this stuff to
userspace, if it was done in multiple stages, we could implement
a form of checkpointing this way.

So instead of doing the 'suspend to disk/ram' after 'write out all pages',
we just continue.

Why is this useful ?  We've seen bugs reported that only ever bite customers
after they've run their workload for a month.  Now, if they had a means
of checkpointing, then when it crashes, they could capture the last image
that landed somewhere, and set that up for more tests/monitoring with kprobes etc
and reproduce those hard-to-reproduce bugs a lot faster.

		Dave

-- 
http://www.codemonkey.org.uk

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Pavel Machek]

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

On Po 13-03-06 16:28:56, Dave Jones wrote:
> On Mon, Mar 13, 2006 at 10:24:20PM +0100, Pavel Machek wrote:
> 
>  > > if suspend-to-disk is fast enough, you could just *always* write
>  > > to disk, even if we're doing S3.  If power runs out, you then have a
>  > > valid resume image on-disk.  iirc, this is what Windows does.
>  > 
>  > Yep, I call that suspend-to-both. It is planned, but not really
>  > trivial, and I'm a little busy. If someone wants to help....
> 
> I was thinking a few days ago. With your move of all this stuff to
> userspace, if it was done in multiple stages, we could implement
> a form of checkpointing this way.

It is possible...

> So instead of doing the 'suspend to disk/ram' after 'write out all pages',
> we just continue.

...but it is not _that_ simple. Preparing video for suspend-to-ram is
rather nasty piece of code, and I'd rather not have it ran after
system is frozen. Sequence needs to be something like:

prepare video for s2ram, vbetool save if neccessary
FREEZE
SNAPSHOT
save image to disk
run s2ram
immediately after wakeup, s-t-disk signature needs to be removed,
	otherwise we risk two resumes from one suspend.

> Why is this useful ?  We've seen bugs reported that only ever bite customers
> after they've run their workload for a month.  Now, if they had a means
> of checkpointing, then when it crashes, they could capture the last image
> that landed somewhere, and set that up for more tests/monitoring with kprobes etc
> and reproduce those hard-to-reproduce bugs a lot faster.

Yes, you can do it, but:

1) each SNAPSHOT takes few seconds, and it is rather disruptive
action -- includes console switch. It needs half of memory free.

2) it only snapshots memory. To be able to continue from saved
snapshot, you'd need to save swap partition and all mounted
filesystems.

Maybe you don't need 2) -- like kernel state is enough for you, or
maybe you can do some magic with device mapper.

Actually I have played with this idea myself. Running system entirely
on ramdisk would make periodic snapshots feasible, and it could do
tricks like system-level undo. Maybe I'll prepare some demo when I get
a time... Its probably going to be toy, through.
								Pavel
-- 
113:

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Nigel Cunningham]

[-- Attachment #1.1: Type: text/plain, Size: 1685 bytes --]

Hi Dave.

On Tuesday 14 March 2006 07:28, Dave Jones wrote:
> On Mon, Mar 13, 2006 at 10:24:20PM +0100, Pavel Machek wrote:
>  > > if suspend-to-disk is fast enough, you could just *always* write
>  > > to disk, even if we're doing S3.  If power runs out, you then have a
>  > > valid resume image on-disk.  iirc, this is what Windows does.
>  >
>  > Yep, I call that suspend-to-both. It is planned, but not really
>  > trivial, and I'm a little busy. If someone wants to help....
>
> I was thinking a few days ago. With your move of all this stuff to
> userspace, if it was done in multiple stages, we could implement
> a form of checkpointing this way.
>
> So instead of doing the 'suspend to disk/ram' after 'write out all pages',
> we just continue.
>
> Why is this useful ?  We've seen bugs reported that only ever bite
> customers after they've run their workload for a month.  Now, if they had a
> means of checkpointing, then when it crashes, they could capture the last
> image that landed somewhere, and set that up for more tests/monitoring with
> kprobes etc and reproduce those hard-to-reproduce bugs a lot faster.

I've been asked about this from time to time too. Apart from the issues Pavel 
has already mentioned, the big problem in my mind was figuring out what to do 
about disk storage. As the algorithm stands at the moment, the image includes 
information about the state of mounted filesystems. We'd need to somehow get 
rid of or be able to ignore that. Any suggestions?

Regards,

Nigel
-- 
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net                IRC: #suspend2 on Freenode

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Rafael J. Wysocki]

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

On Monday 13 March 2006 22:46, Pavel Machek wrote:
> On Po 13-03-06 16:28:56, Dave Jones wrote:
> > On Mon, Mar 13, 2006 at 10:24:20PM +0100, Pavel Machek wrote:
> > 
> >  > > if suspend-to-disk is fast enough, you could just *always* write
> >  > > to disk, even if we're doing S3.  If power runs out, you then have a
> >  > > valid resume image on-disk.  iirc, this is what Windows does.
> >  > 
> >  > Yep, I call that suspend-to-both. It is planned, but not really
> >  > trivial, and I'm a little busy. If someone wants to help....
> > 
> > I was thinking a few days ago. With your move of all this stuff to
> > userspace, if it was done in multiple stages, we could implement
> > a form of checkpointing this way.
> 
> It is possible...
> 
> > So instead of doing the 'suspend to disk/ram' after 'write out all pages',
> > we just continue.
> 
> ...but it is not _that_ simple. Preparing video for suspend-to-ram is
> rather nasty piece of code, and I'd rather not have it ran after
> system is frozen. Sequence needs to be something like:
> 
> prepare video for s2ram, vbetool save if neccessary
> FREEZE
> SNAPSHOT
> save image to disk
> run s2ram
> immediately after wakeup, s-t-disk signature needs to be removed,
> 	otherwise we risk two resumes from one suspend.
> 
> > Why is this useful ?  We've seen bugs reported that only ever bite customers
> > after they've run their workload for a month.  Now, if they had a means
> > of checkpointing, then when it crashes, they could capture the last image
> > that landed somewhere, and set that up for more tests/monitoring with kprobes etc
> > and reproduce those hard-to-reproduce bugs a lot faster.
> 
> Yes, you can do it, but:
> 
> 1) each SNAPSHOT takes few seconds, and it is rather disruptive
> action -- includes console switch. It needs half of memory free.
> 
> 2) it only snapshots memory. To be able to continue from saved
> snapshot, you'd need to save swap partition and all mounted
> filesystems.
> 
> Maybe you don't need 2) -- like kernel state is enough for you, or
> maybe you can do some magic with device mapper.

Still, if you make any changes to mounted filesystems after the snapshot has
been made, you can't use it any more, because it "remembers" the state of the
filesystems _without_ the changes.

To work around this you'll have to make sure all of the filesystems-related
information will be reread from the actual storage after the snapshot has
been "reloaded".

Greetings,
Rafael

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Pavel Machek]

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

Hi!

> >  > Yep, I call that suspend-to-both. It is planned, but not really
> >  > trivial, and I'm a little busy. If someone wants to help....
> >
> > I was thinking a few days ago. With your move of all this stuff to
> > userspace, if it was done in multiple stages, we could implement
> > a form of checkpointing this way.
> >
> > So instead of doing the 'suspend to disk/ram' after 'write out all pages',
> > we just continue.
> >
> > Why is this useful ?  We've seen bugs reported that only ever bite
> > customers after they've run their workload for a month.  Now, if they had a
> > means of checkpointing, then when it crashes, they could capture the last
> > image that landed somewhere, and set that up for more tests/monitoring with
> > kprobes etc and reproduce those hard-to-reproduce bugs a lot faster.
> 
> I've been asked about this from time to time too. Apart from the issues Pavel 
> has already mentioned, the big problem in my mind was figuring out what to do 
> about disk storage. As the algorithm stands at the moment, the image includes 
> information about the state of mounted filesystems. We'd need to somehow get 
> rid of or be able to ignore that. Any suggestions?

Well, copying all the filesystems would work, as would having no
filesystems at all :-) [ramdisk case]. And perhaps practical
equivalent of "copy all filesystems" can be done with device mapper.

[Of course, you'd have to copy all the filesystems back before doing
resume].

							Pavel
-- 
116:

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Rafael J. Wysocki]

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

On Monday 13 March 2006 23:08, Pavel Machek wrote:
> > >  > Yep, I call that suspend-to-both. It is planned, but not really
> > >  > trivial, and I'm a little busy. If someone wants to help....
> > >
> > > I was thinking a few days ago. With your move of all this stuff to
> > > userspace, if it was done in multiple stages, we could implement
> > > a form of checkpointing this way.
> > >
> > > So instead of doing the 'suspend to disk/ram' after 'write out all pages',
> > > we just continue.
> > >
> > > Why is this useful ?  We've seen bugs reported that only ever bite
> > > customers after they've run their workload for a month.  Now, if they had a
> > > means of checkpointing, then when it crashes, they could capture the last
> > > image that landed somewhere, and set that up for more tests/monitoring with
> > > kprobes etc and reproduce those hard-to-reproduce bugs a lot faster.
> > 
> > I've been asked about this from time to time too. Apart from the issues Pavel 
> > has already mentioned, the big problem in my mind was figuring out what to do 
> > about disk storage. As the algorithm stands at the moment, the image includes 
> > information about the state of mounted filesystems. We'd need to somehow get 
> > rid of or be able to ignore that. Any suggestions?
> 
> Well, copying all the filesystems would work, as would having no
> filesystems at all :-) [ramdisk case]. And perhaps practical
> equivalent of "copy all filesystems" can be done with device mapper.
> 
> [Of course, you'd have to copy all the filesystems back before doing
> resume].

If we had anything like fs suspend/resume, we could handle such things.
We could also handle the "USB device mounted before suspend" problem
(I think it's related).

Greetings,
Rafael

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Nigel Cunningham]

[-- Attachment #1.1: Type: text/plain, Size: 2820 bytes --]

Hi.

On Tuesday 14 March 2006 08:42, Rafael J. Wysocki wrote:
> On Monday 13 March 2006 23:08, Pavel Machek wrote:
> > > >  > Yep, I call that suspend-to-both. It is planned, but not really
> > > >  > trivial, and I'm a little busy. If someone wants to help....
> > > >
> > > > I was thinking a few days ago. With your move of all this stuff to
> > > > userspace, if it was done in multiple stages, we could implement
> > > > a form of checkpointing this way.
> > > >
> > > > So instead of doing the 'suspend to disk/ram' after 'write out all
> > > > pages', we just continue.
> > > >
> > > > Why is this useful ?  We've seen bugs reported that only ever bite
> > > > customers after they've run their workload for a month.  Now, if they
> > > > had a means of checkpointing, then when it crashes, they could
> > > > capture the last image that landed somewhere, and set that up for
> > > > more tests/monitoring with kprobes etc and reproduce those
> > > > hard-to-reproduce bugs a lot faster.
> > >
> > > I've been asked about this from time to time too. Apart from the issues
> > > Pavel has already mentioned, the big problem in my mind was figuring
> > > out what to do about disk storage. As the algorithm stands at the
> > > moment, the image includes information about the state of mounted
> > > filesystems. We'd need to somehow get rid of or be able to ignore that.
> > > Any suggestions?
> >
> > Well, copying all the filesystems would work, as would having no
> > filesystems at all :-) [ramdisk case]. And perhaps practical
> > equivalent of "copy all filesystems" can be done with device mapper.
> >
> > [Of course, you'd have to copy all the filesystems back before doing
> > resume].
>
> If we had anything like fs suspend/resume, we could handle such things.
> We could also handle the "USB device mounted before suspend" problem
> (I think it's related).

Well, we have bdev freezing, which I guess is what is used for fixing up raid 
mirrors (but don't know for certain). I use it in refrigerating to get XFS to 
really stop activity. I don't think it helps in this case though:

We need to be able to rollback the state of the filesystem in memory and on 
disk to the point where the last checkpoint was made. Memory would be 
straight forward if we want to do it dumbly and slowly - just reload the 
whole check pointed image. If we want to be more efficient, we'd want to just 
load the pages that had changed (Mark on (first) write?). But filesystems 
seem to be a whole different story. Do any of the commonly used fses have 
support for checkpointing and rollback back at the moment?

Regards,

Nigel
-- 
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net                IRC: #suspend2 on Freenode

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Rafael J. Wysocki]

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

Hi,

On Tuesday 14 March 2006 00:11, Nigel Cunningham wrote:
> On Tuesday 14 March 2006 08:42, Rafael J. Wysocki wrote:
> > On Monday 13 March 2006 23:08, Pavel Machek wrote:
> > > > >  > Yep, I call that suspend-to-both. It is planned, but not really
> > > > >  > trivial, and I'm a little busy. If someone wants to help....
> > > > >
> > > > > I was thinking a few days ago. With your move of all this stuff to
> > > > > userspace, if it was done in multiple stages, we could implement
> > > > > a form of checkpointing this way.
> > > > >
> > > > > So instead of doing the 'suspend to disk/ram' after 'write out all
> > > > > pages', we just continue.
> > > > >
> > > > > Why is this useful ?  We've seen bugs reported that only ever bite
> > > > > customers after they've run their workload for a month.  Now, if they
> > > > > had a means of checkpointing, then when it crashes, they could
> > > > > capture the last image that landed somewhere, and set that up for
> > > > > more tests/monitoring with kprobes etc and reproduce those
> > > > > hard-to-reproduce bugs a lot faster.
> > > >
> > > > I've been asked about this from time to time too. Apart from the issues
> > > > Pavel has already mentioned, the big problem in my mind was figuring
> > > > out what to do about disk storage. As the algorithm stands at the
> > > > moment, the image includes information about the state of mounted
> > > > filesystems. We'd need to somehow get rid of or be able to ignore that.
> > > > Any suggestions?
> > >
> > > Well, copying all the filesystems would work, as would having no
> > > filesystems at all :-) [ramdisk case]. And perhaps practical
> > > equivalent of "copy all filesystems" can be done with device mapper.
> > >
> > > [Of course, you'd have to copy all the filesystems back before doing
> > > resume].
> >
> > If we had anything like fs suspend/resume, we could handle such things.
> > We could also handle the "USB device mounted before suspend" problem
> > (I think it's related).
> 
> Well, we have bdev freezing, which I guess is what is used for fixing up raid 
> mirrors (but don't know for certain). I use it in refrigerating to get XFS to 
> really stop activity. I don't think it helps in this case though:

I don't think so too.

> We need to be able to rollback the state of the filesystem in memory and on 
> disk to the point where the last checkpoint was made. Memory would be 
> straight forward if we want to do it dumbly and slowly - just reload the 
> whole check pointed image. If we want to be more efficient, we'd want to just 
> load the pages that had changed (Mark on (first) write?). But filesystems 
> seem to be a whole different story. Do any of the commonly used fses have 
> support for checkpointing and rollback back at the moment?

I'm not sure if we need a rollback as such.  What we need is to make sure
the filesystems state will be consistent before as well as after we have
"reloaded" the snapshot.

Greetings,
Rafael

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Nigel Cunningham]

[-- Attachment #1.1: Type: text/plain, Size: 3923 bytes --]

Hi.

On Tuesday 14 March 2006 09:36, Rafael J. Wysocki wrote:
> Hi,
>
> On Tuesday 14 March 2006 00:11, Nigel Cunningham wrote:
> > On Tuesday 14 March 2006 08:42, Rafael J. Wysocki wrote:
> > > On Monday 13 March 2006 23:08, Pavel Machek wrote:
> > > > > >  > Yep, I call that suspend-to-both. It is planned, but not
> > > > > >  > really trivial, and I'm a little busy. If someone wants to
> > > > > >  > help....
> > > > > >
> > > > > > I was thinking a few days ago. With your move of all this stuff
> > > > > > to userspace, if it was done in multiple stages, we could
> > > > > > implement a form of checkpointing this way.
> > > > > >
> > > > > > So instead of doing the 'suspend to disk/ram' after 'write out
> > > > > > all pages', we just continue.
> > > > > >
> > > > > > Why is this useful ?  We've seen bugs reported that only ever
> > > > > > bite customers after they've run their workload for a month. 
> > > > > > Now, if they had a means of checkpointing, then when it crashes,
> > > > > > they could capture the last image that landed somewhere, and set
> > > > > > that up for more tests/monitoring with kprobes etc and reproduce
> > > > > > those hard-to-reproduce bugs a lot faster.
> > > > >
> > > > > I've been asked about this from time to time too. Apart from the
> > > > > issues Pavel has already mentioned, the big problem in my mind was
> > > > > figuring out what to do about disk storage. As the algorithm stands
> > > > > at the moment, the image includes information about the state of
> > > > > mounted filesystems. We'd need to somehow get rid of or be able to
> > > > > ignore that. Any suggestions?
> > > >
> > > > Well, copying all the filesystems would work, as would having no
> > > > filesystems at all :-) [ramdisk case]. And perhaps practical
> > > > equivalent of "copy all filesystems" can be done with device mapper.
> > > >
> > > > [Of course, you'd have to copy all the filesystems back before doing
> > > > resume].
> > >
> > > If we had anything like fs suspend/resume, we could handle such things.
> > > We could also handle the "USB device mounted before suspend" problem
> > > (I think it's related).
> >
> > Well, we have bdev freezing, which I guess is what is used for fixing up
> > raid mirrors (but don't know for certain). I use it in refrigerating to
> > get XFS to really stop activity. I don't think it helps in this case
> > though:
>
> I don't think so too.
>
> > We need to be able to rollback the state of the filesystem in memory and
> > on disk to the point where the last checkpoint was made. Memory would be
> > straight forward if we want to do it dumbly and slowly - just reload the
> > whole check pointed image. If we want to be more efficient, we'd want to
> > just load the pages that had changed (Mark on (first) write?). But
> > filesystems seem to be a whole different story. Do any of the commonly
> > used fses have support for checkpointing and rollback back at the moment?
>
> I'm not sure if we need a rollback as such.  What we need is to make sure
> the filesystems state will be consistent before as well as after we have
> "reloaded" the snapshot.

Rereading what I think was Dave's original comment above (bug reports that 
only bite customers...), I think the requirement is to be able to rollback 
the entire system to the checkpoint - not merely ensure it's consistent, but 
ensure it's the same so that (all other things being equal), the bug could be 
reproduced with the extra instrumentation in place. Having a filesystem that 
was consistent but (say) discarding the inodes and dentries in memory at the 
time of the checkpoint might be throwing away the very data required to 
reproduce the bug.

HTH.

Nigel
-- 
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net                IRC: #suspend2 on Freenode

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Nigel Cunningham]

[-- Attachment #1.1: Type: text/plain, Size: 2260 bytes --]

Hi.

On Tuesday 14 March 2006 07:24, Pavel Machek wrote:
> On Po 13-03-06 13:33:18, Dave Jones wrote:
> > On Mon, Mar 13, 2006 at 10:13:32AM +0100, Pavel Machek wrote:
> >  > On Po 13-03-06 04:07:59, Adam Belay wrote:
> >  > > On Mon, Mar 13, 2006 at 09:50:42AM +0100, Pavel Machek wrote:
> >  > > > On Po 13-03-06 03:48:11, Adam Belay wrote:
> >  > > > > The timeout feature could be done using the ACPI alarm
> >  > > > > interface, but there's no reliable way of knowing how long the
> >  > > > > system can remain in a suspend state on the x86 mobile platform,
> >  > > > > so waking up at the right time would be tricky if not
> >  > > > > impossible.
> >  > > >
> >  > > > Make it an hour... System should be able to stay suspended for an
> >  > > > hour. IIRC Apple did something like this? I'd just be slightly
> >  > > > worried about machine waking up itself just when you hit the
> >  > > > turbulence in the airplane, or something like that.
> >  > >
> >  > > Hmm, but let's say the battery is 40% charged.  Then it's not very
> >  > > clear if it will last an hour.  All of a sudden the issue becomes
> >  > > system specific, or it may even depend on things like whether
> >  > > wake-on-lan is enabled, right?
> >  >
> >  > 40% battery should still last 10+ hours in suspend-to-RAM, unless
> >  > something is wrong.
> >  >
> >  > You *could* wakeup every minute or so to check the battery state; some
> >  > PDAs actually do that.
> >
> > if suspend-to-disk is fast enough, you could just *always* write
> > to disk, even if we're doing S3.  If power runs out, you then have a
> > valid resume image on-disk.  iirc, this is what Windows does.
>
> Yep, I call that suspend-to-both. It is planned, but not really
> trivial, and I'm a little busy. If someone wants to help....

Actually it is really easy to do Pavel, so long as your code already has the 
error handling that allows it to back out nicely. Just enter S3 at the point 
where you'd otherwise power down, then on resume act like an error occured at 
the last moment and back out.

Regards,

Nigel

-- 
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net                IRC: #suspend2 on Freenode

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Pavel Machek]

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

> > > if suspend-to-disk is fast enough, you could just *always* write
> > > to disk, even if we're doing S3.  If power runs out, you then have a
> > > valid resume image on-disk.  iirc, this is what Windows does.
> >
> > Yep, I call that suspend-to-both. It is planned, but not really
> > trivial, and I'm a little busy. If someone wants to help....
> 
> Actually it is really easy to do Pavel, so long as your code already has the 
> error handling that allows it to back out nicely. Just enter S3 at the point 
> where you'd otherwise power down, then on resume act like an error occured at 
> the last moment and back out.

Entering S3 is not trivial operation, that's the problem. vbetool save
is needed on some machines (needs filesystem), for example. Yep, it
should not be hard.

Minor surgery will be needed to allow suspend-to-ram on already frozen
system...

								Pavel
-- 
57:        MD5CryptoServiceProvider MD5 = new MD5CryptoServiceProvider();

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Rafael J. Wysocki]

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

On Tuesday 14 March 2006 01:18, Nigel Cunningham wrote:
> On Tuesday 14 March 2006 09:36, Rafael J. Wysocki wrote:
> > On Tuesday 14 March 2006 00:11, Nigel Cunningham wrote:
> > > On Tuesday 14 March 2006 08:42, Rafael J. Wysocki wrote:
> > > > On Monday 13 March 2006 23:08, Pavel Machek wrote:
> > > > > > >  > Yep, I call that suspend-to-both. It is planned, but not
> > > > > > >  > really trivial, and I'm a little busy. If someone wants to
> > > > > > >  > help....
> > > > > > >
> > > > > > > I was thinking a few days ago. With your move of all this stuff
> > > > > > > to userspace, if it was done in multiple stages, we could
> > > > > > > implement a form of checkpointing this way.
> > > > > > >
> > > > > > > So instead of doing the 'suspend to disk/ram' after 'write out
> > > > > > > all pages', we just continue.
> > > > > > >
> > > > > > > Why is this useful ?  We've seen bugs reported that only ever
> > > > > > > bite customers after they've run their workload for a month. 
> > > > > > > Now, if they had a means of checkpointing, then when it crashes,
> > > > > > > they could capture the last image that landed somewhere, and set
> > > > > > > that up for more tests/monitoring with kprobes etc and reproduce
> > > > > > > those hard-to-reproduce bugs a lot faster.
> > > > > >
> > > > > > I've been asked about this from time to time too. Apart from the
> > > > > > issues Pavel has already mentioned, the big problem in my mind was
> > > > > > figuring out what to do about disk storage. As the algorithm stands
> > > > > > at the moment, the image includes information about the state of
> > > > > > mounted filesystems. We'd need to somehow get rid of or be able to
> > > > > > ignore that. Any suggestions?
> > > > >
> > > > > Well, copying all the filesystems would work, as would having no
> > > > > filesystems at all :-) [ramdisk case]. And perhaps practical
> > > > > equivalent of "copy all filesystems" can be done with device mapper.
> > > > >
> > > > > [Of course, you'd have to copy all the filesystems back before doing
> > > > > resume].
> > > >
> > > > If we had anything like fs suspend/resume, we could handle such things.
> > > > We could also handle the "USB device mounted before suspend" problem
> > > > (I think it's related).
> > >
> > > Well, we have bdev freezing, which I guess is what is used for fixing up
> > > raid mirrors (but don't know for certain). I use it in refrigerating to
> > > get XFS to really stop activity. I don't think it helps in this case
> > > though:
> >
> > I don't think so too.
> >
> > > We need to be able to rollback the state of the filesystem in memory and
> > > on disk to the point where the last checkpoint was made. Memory would be
> > > straight forward if we want to do it dumbly and slowly - just reload the
> > > whole check pointed image. If we want to be more efficient, we'd want to
> > > just load the pages that had changed (Mark on (first) write?). But
> > > filesystems seem to be a whole different story. Do any of the commonly
> > > used fses have support for checkpointing and rollback back at the moment?
> >
> > I'm not sure if we need a rollback as such.  What we need is to make sure
> > the filesystems state will be consistent before as well as after we have
> > "reloaded" the snapshot.
> 
> Rereading what I think was Dave's original comment above (bug reports that 
> only bite customers...), I think the requirement is to be able to rollback 
> the entire system to the checkpoint - not merely ensure it's consistent, but 
> ensure it's the same so that (all other things being equal), the bug could be 
> reproduced with the extra instrumentation in place. Having a filesystem that 
> was consistent but (say) discarding the inodes and dentries in memory at the 
> time of the checkpoint might be throwing away the very data required to 
> reproduce the bug.

Right, but it still would be useful for tracing bugs that are not related to
filesystems, I think.  Moreover, it would also be useful for other purposes
(the USB devices problem, retrying to resume after fixing some hardware).

Greetings,
Rafael

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Pavel Machek]

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

Hi!

> > > Well, copying all the filesystems would work, as would having no
> > > filesystems at all :-) [ramdisk case]. And perhaps practical
> > > equivalent of "copy all filesystems" can be done with device mapper.
> > >
> > > [Of course, you'd have to copy all the filesystems back before doing
> > > resume].
> >
> > If we had anything like fs suspend/resume, we could handle such things.
> > We could also handle the "USB device mounted before suspend" problem
> > (I think it's related).
> 
> Well, we have bdev freezing, which I guess is what is used for fixing up raid 
> mirrors (but don't know for certain). I use it in refrigerating to get XFS to 
> really stop activity. I don't think it helps in this case though:
> 
> We need to be able to rollback the state of the filesystem in memory and on 
> disk to the point where the last checkpoint was made. Memory would be 
> straight forward if we want to do it dumbly and slowly - just reload the 
> whole check pointed image. If we want to be more efficient, we'd want to just 
> load the pages that had changed (Mark on (first) write?). But filesystems 
> seem to be a whole different story. Do any of the commonly used fses have 
> support for checkpointing and rollback back at the moment?

AFAIK, such support exists at "device mapper" level.
									Pavel
-- 
179:        alg.Mode = CipherMode.CBC;

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Pavel Machek]

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

Hi!

> > We need to be able to rollback the state of the filesystem in memory and on 
> > disk to the point where the last checkpoint was made. Memory would be 
> > straight forward if we want to do it dumbly and slowly - just reload the 
> > whole check pointed image. If we want to be more efficient, we'd want to just 
> > load the pages that had changed (Mark on (first) write?). But filesystems 
> > seem to be a whole different story. Do any of the commonly used fses have 
> > support for checkpointing and rollback back at the moment?
> 
> I'm not sure if we need a rollback as such.  What we need is to make sure
> the filesystems state will be consistent before as well as after we have
> "reloaded" the snapshot.

Even if you make sure *kernel* is consistent with changed filesystem,
userland is going to be badly confused. Imagine what will happen with
memory mapped files, for example. 

I'm not sure how it could work...
								Pavel
-- 
130:        Buffer.BlockCopy( sbuffer, Pos + 4, Bytes, 0, Bytes.Length );

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Rafael J. Wysocki]

Hi,

On Tuesday 14 March 2006 21:33, Pavel Machek wrote:
> > > We need to be able to rollback the state of the filesystem in memory and on 
> > > disk to the point where the last checkpoint was made. Memory would be 
> > > straight forward if we want to do it dumbly and slowly - just reload the 
> > > whole check pointed image. If we want to be more efficient, we'd want to just 
> > > load the pages that had changed (Mark on (first) write?). But filesystems 
> > > seem to be a whole different story. Do any of the commonly used fses have 
> > > support for checkpointing and rollback back at the moment?
> > 
> > I'm not sure if we need a rollback as such.  What we need is to make sure
> > the filesystems state will be consistent before as well as after we have
> > "reloaded" the snapshot.
> 
> Even if you make sure *kernel* is consistent with changed filesystem,
> userland is going to be badly confused. Imagine what will happen with
> memory mapped files, for example. 

Something like what happens when you suspend with a mounted CD
and mmapped files from there, then you replace the CD while suspended
and resume.  Not a wise thing to do, but I think people will do such things
from time to time and we'd better be prepared to handle them nicely.

> I'm not sure how it could work...

IMO memory mapped files are the most difficult problem here,
but the rest seems to be doable in general.

Rafael

Re: Re: standby to disk transition

[Pavel Machek]

On Út 14-03-06 22:13:02, Rafael J. Wysocki wrote:
> Hi,
> 
> On Tuesday 14 March 2006 21:33, Pavel Machek wrote:
> > > > We need to be able to rollback the state of the filesystem in memory and on 
> > > > disk to the point where the last checkpoint was made. Memory would be 
> > > > straight forward if we want to do it dumbly and slowly - just reload the 
> > > > whole check pointed image. If we want to be more efficient, we'd want to just 
> > > > load the pages that had changed (Mark on (first) write?). But filesystems 
> > > > seem to be a whole different story. Do any of the commonly used fses have 
> > > > support for checkpointing and rollback back at the moment?
> > > 
> > > I'm not sure if we need a rollback as such.  What we need is to make sure
> > > the filesystems state will be consistent before as well as after we have
> > > "reloaded" the snapshot.
> > 
> > Even if you make sure *kernel* is consistent with changed filesystem,
> > userland is going to be badly confused. Imagine what will happen with
> > memory mapped files, for example. 
> 
> Something like what happens when you suspend with a mounted CD
> and mmapped files from there, then you replace the CD while suspended
> and resume.  Not a wise thing to do, but I think people will do such things
> from time to time and we'd better be prepared to handle them nicely.

But... we can't prevent userspace from segfaulting in such case... can
we?

> > I'm not sure how it could work...
> 
> IMO memory mapped files are the most difficult problem here,
> but the rest seems to be doable in general.

It seems to be the same problem with removable media... You could
replace mounted CDrom while running. (Not all CDroms support door
lock.)
								Pavel
-- 
14:        {

Re: Re: standby to disk transition

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1792 bytes --]

On Tue, 14 Mar 2006, Pavel Machek wrote:

> > > Even if you make sure *kernel* is consistent with changed filesystem,
> > > userland is going to be badly confused. Imagine what will happen with
> > > memory mapped files, for example. 
> > 
> > Something like what happens when you suspend with a mounted CD
> > and mmapped files from there, then you replace the CD while suspended
> > and resume.  Not a wise thing to do, but I think people will do such things
> > from time to time and we'd better be prepared to handle them nicely.
> 
> But... we can't prevent userspace from segfaulting in such case... can
> we?
> 
> > > I'm not sure how it could work...
> > 
> > IMO memory mapped files are the most difficult problem here,
> > but the rest seems to be doable in general.
> 
> It seems to be the same problem with removable media... You could
> replace mounted CDrom while running. (Not all CDroms support door
> lock.)

In theory, any SCSI device is supposed to realize when the medium has been 
changed and notify the host by responding to the next command with a Unit 
Attention sense key.  That's how medium changes while the system _isn't_ 
suspended get detected.

The situation becomes much more problematic when the SCSI device itself is
powered off.  In that case (which includes the "hardware doesn't support
USB power during suspend" problem discussed at great length earlier), the
kernel has only two choices.  Either assume that the medium _has_ been
changed -- or more generally, that a new device is present -- or else try
to verify somehow that the current medium is the same as the old medium.

This verification can't be certain, so there would always be a chance for 
error.  Besides, right now the kernel contains no code for making such 
verifications.

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Rafael J. Wysocki]

Hi,

On Tuesday 14 March 2006 22:22, Pavel Machek wrote:
> On Út 14-03-06 22:13:02, Rafael J. Wysocki wrote:
> > On Tuesday 14 March 2006 21:33, Pavel Machek wrote:
> > > > > We need to be able to rollback the state of the filesystem in memory and on 
> > > > > disk to the point where the last checkpoint was made. Memory would be 
> > > > > straight forward if we want to do it dumbly and slowly - just reload the 
> > > > > whole check pointed image. If we want to be more efficient, we'd want to just 
> > > > > load the pages that had changed (Mark on (first) write?). But filesystems 
> > > > > seem to be a whole different story. Do any of the commonly used fses have 
> > > > > support for checkpointing and rollback back at the moment?
> > > > 
> > > > I'm not sure if we need a rollback as such.  What we need is to make sure
> > > > the filesystems state will be consistent before as well as after we have
> > > > "reloaded" the snapshot.
> > > 
> > > Even if you make sure *kernel* is consistent with changed filesystem,
> > > userland is going to be badly confused. Imagine what will happen with
> > > memory mapped files, for example. 
> > 
> > Something like what happens when you suspend with a mounted CD
> > and mmapped files from there, then you replace the CD while suspended
> > and resume.  Not a wise thing to do, but I think people will do such things
> > from time to time and we'd better be prepared to handle them nicely.
> 
> But... we can't prevent userspace from segfaulting in such case... can
> we?

If we know the filesystem is gone before the applications have a chance
to do anything, like on resume, we can.  Eventually we can just kill all of the
processes that use memory mapped files from the missing filesystem.
That would be a bit drastic, though. ;-)

> > > I'm not sure how it could work...
> > 
> > IMO memory mapped files are the most difficult problem here,
> > but the rest seems to be doable in general.
> 
> It seems to be the same problem with removable media... You could
> replace mounted CDrom while running. (Not all CDroms support door
> lock.)

Yes, but there are two distinct classes of cases:
(1) we know the media has been removed before any process tries to access it
(eg. the related bus driver detects the disconnect, like USB)
(2) we have no means to detect the removal of the media except for trying to
access it.

For the class (1) of events we can do some clean-up work,at least in principle,
and we are talking of such a case, IMO.

Greetings,
Rafael

Re: Re: standby to disk transition

[Pavel Machek]

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

Hi!

Just a preview of what I'm working on: suspend-to-both
implementation. Be *very* careful with it.


===================================================================
RCS file: /cvsroot/suspend/suspend/Makefile,v
retrieving revision 1.21
diff -u -u -r1.21 Makefile
--- Makefile	12 Mar 2006 16:17:19 -0000	1.21
+++ Makefile	14 Mar 2006 21:55:40 -0000
@@ -1,5 +1,5 @@
 #CONFIG_COMPRESS=yes
-#CONFIG_ENCRYPT=yes
+CONFIG_ENCRYPT=yes
 
 CC_FLAGS=-I/usr/local/include
 LD_FLAGS=-L/usr/local/lib
@@ -69,8 +69,8 @@
 vt.o:	vt.c vt.h
 	gcc -Wall -c vt.c
 
-suspend:	md5.o encrypt.o config.o suspend.c swsusp.h config.h encrypt.h md5.h
-	gcc -Wall $(CC_FLAGS) md5.o encrypt.o config.o suspend.c -o suspend $(LD_FLAGS)
+suspend:	md5.o encrypt.o config.o suspend.c swsusp.h config.h encrypt.h md5.h s2ram.c dmidecode.c whitelist.c radeontool.c $(S2RAMOBJ)
+	gcc -g -O2 -DCONFIG_BOTH -Wall $(CC_FLAGS) md5.o encrypt.o config.o suspend.c s2ram.c -o suspend $(S2RAMOBJ) $(LD_FLAGS) -lpci 
 
 resume:	md5.o encrypt.o config.o resume.c swsusp.h config.h encrypt.h md5.h
 	gcc -Wall $(CC_FLAGS) md5.o encrypt.o config.o resume.c -static -o resume $(LD_FLAGS)
Index: s2ram.c
===================================================================
RCS file: /cvsroot/suspend/suspend/s2ram.c,v
retrieving revision 1.29
diff -u -u -r1.29 s2ram.c
--- s2ram.c	7 Mar 2006 23:54:21 -0000	1.29
+++ s2ram.c	14 Mar 2006 21:55:44 -0000
@@ -162,9 +162,11 @@
 		vbe_buffer = __save_state(&size);
 	}
 	if (flags & RADEON_OFF) {
+#if 0
 		map_radeon_cntl_mem();
 		printf("Calling radeon_cmd_light");
 		radeon_cmd_light("off");
+#endif
 	}
 }
 
@@ -237,6 +239,7 @@
 	exit(1);
 }
 
+#ifndef CONFIG_BOTH
 int main(int argc, char *argv[])
 {
 	int i;
@@ -299,3 +302,4 @@
 	s2ram_resume();
 	return i;
 }
+#endif
Index: suspend.c
===================================================================
RCS file: /cvsroot/suspend/suspend/suspend.c,v
retrieving revision 1.22
diff -u -u -r1.22 suspend.c
--- suspend.c	12 Mar 2006 16:17:19 -0000	1.22
+++ suspend.c	14 Mar 2006 21:55:58 -0000
@@ -53,6 +53,7 @@
 #define encrypt 0
 #define key_name NULL
 #endif
+static int s2ram = 1;
 
 static struct config_par parameters[PARAM_NO] = {
 	{
@@ -518,6 +519,50 @@
 						ioctl(fd, VT_WAITACTIVE, vt); \
 						ioctl(fd, KDSKBMODE, ioc2);
 
+
+static int reset_signature(int fd)
+{
+	static struct swap_map_handle handle;
+	int ret, error = 0;
+	struct swsusp_info *header;
+	char c;
+
+	ret = lseek(fd, 0, SEEK_SET);
+	if (!ret)
+		return -errno;
+	memset(&swsusp_header, 0, sizeof(swsusp_header));
+	ret = read(fd, &swsusp_header, PAGE_SIZE);
+	if (ret == PAGE_SIZE) {
+		if (memcmp(SWSUSP_SIG, swsusp_header.sig, 10))
+			/* Impossible? We wrote signature and it is not there?! */
+			return -EINVAL;
+	} else {
+		error = ret < 0 ? ret : -EIO;
+	}
+
+	if (!error || !ret) {
+		/* Reset swap signature now */
+		memcpy(swsusp_header.sig, swsusp_header.orig_sig, 10);
+		ret = lseek(fd, 0, SEEK_SET);
+		if (!ret)
+			ret = write(fd, &swsusp_header, PAGE_SIZE);
+		if (ret < (int)PAGE_SIZE) {
+			fprintf(stderr, "resume: Could not restore the partition header\n");
+			error = ret < 0 ? -errno : -EIO;
+		}
+	}
+	fsync(fd);
+	close(fd);
+	if (!error) {
+		printf("reset_signature: Signature reset ok\n");
+	} else {
+		printf("reset_signature: Error %d resetting the image. Something went very wrong please reboot machine manually, destroy saved image, and force fsck.\n"
+			"\n", error);
+		while(1);
+	}
+	return error;
+}
+
 int suspend_system(int snapshot_fd, int resume_fd, int vt_fd, int vt_no)
 {
 	loff_t avail_swap;
@@ -552,7 +597,15 @@
 				break;
 			error = write_image(snapshot_fd, resume_fd);
 			if (!error) {
-				power_off();
+				if (!s2ram)
+					power_off();
+				else {
+					s2ram_do();
+					s2ram_resume();
+					error = EDOM;
+					reset_signature(snapshot_fd);
+					break;
+				}
 			} else {
 				free_swap_pages(snapshot_fd);
 				free_snapshot(snapshot_fd);
@@ -569,6 +622,7 @@
 
 Unfreeze:
 	unfreeze(snapshot_fd);
+	/* FIXME: We have to kill the signature here */
 
 	return error;
 }
@@ -779,7 +833,6 @@
 	if (stat(resume_dev_name, &stat_buf)) {
 		fprintf(stderr, "suspend: Could not stat the resume device file\n");
 		return ENODEV;
-	} else {
 	}
 	if (!S_ISBLK(stat_buf.st_mode)) {
 		fprintf(stderr, "suspend: Invalid resume device\n");
@@ -797,6 +850,10 @@
 		ret = ENODEV;
 		goto Close_resume_fd;
 	}
+
+	if (s2ram)
+		s2ram_prepare();
+
 	if (!S_ISCHR(stat_buf.st_mode)) {
 		fprintf(stderr, "suspend: Invalid snapshot device\n");
 		ret = EINVAL;
@@ -823,6 +880,7 @@
 		goto Close_snapshot_fd;
 	}
 
+#if 0
 	sprintf(chroot_path, "/proc/%d", getpid());
 	if (chroot(chroot_path)) {
 		fprintf(stderr, "suspend: Could not chroot to %s\n", chroot_path);
@@ -830,6 +888,7 @@
 		goto Restore_console;
 	}
 	chdir("/");
+#endif
 
 	orig_loglevel = get_kernel_console_loglevel();
 	set_kernel_console_loglevel(suspend_loglevel);

-- 
53:        Decrypt( adPRIV, 0, adPRIV.Length, UserKey, MD5.Hash );

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Rafael J. Wysocki]

On Tuesday 14 March 2006 22:42, Alan Stern wrote:
> On Tue, 14 Mar 2006, Pavel Machek wrote:
> 
> > > > Even if you make sure *kernel* is consistent with changed filesystem,
> > > > userland is going to be badly confused. Imagine what will happen with
> > > > memory mapped files, for example. 
> > > 
> > > Something like what happens when you suspend with a mounted CD
> > > and mmapped files from there, then you replace the CD while suspended
> > > and resume.  Not a wise thing to do, but I think people will do such things
> > > from time to time and we'd better be prepared to handle them nicely.
> > 
> > But... we can't prevent userspace from segfaulting in such case... can
> > we?
> > 
> > > > I'm not sure how it could work...
> > > 
> > > IMO memory mapped files are the most difficult problem here,
> > > but the rest seems to be doable in general.
> > 
> > It seems to be the same problem with removable media... You could
> > replace mounted CDrom while running. (Not all CDroms support door
> > lock.)
> 
> In theory, any SCSI device is supposed to realize when the medium has been 
> changed and notify the host by responding to the next command with a Unit 
> Attention sense key.  That's how medium changes while the system _isn't_ 
> suspended get detected.
> 
> The situation becomes much more problematic when the SCSI device itself is
> powered off.  In that case (which includes the "hardware doesn't support
> USB power during suspend" problem discussed at great length earlier), the
> kernel has only two choices.  Either assume that the medium _has_ been
> changed -- or more generally, that a new device is present -- or else try
> to verify somehow that the current medium is the same as the old medium.
> 
> This verification can't be certain, so there would always be a chance for 
> error.  Besides, right now the kernel contains no code for making such 
> verifications.

The question here, as far as I understand it, is whether we can write such a
code and, if so, whether it's worth doing.  I'm not sure of any of these now,
but the problem is interesting. :-)

Greetings,
Rafael

suspend-to-both [was Re: Re: standby to disk transition]

[Pavel Machek]

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

Hi!

suspend-to-both implementation that actually works, but I had to
disable some safety checks, and yes, it needs cleanups... It also
produces some ugly warning because we call thaw_processes() twice in a
row. But seems to work.
								Pavel

Index: Makefile
===================================================================
RCS file: /cvsroot/suspend/suspend/Makefile,v
retrieving revision 1.21
diff -u -u -r1.21 Makefile
--- Makefile	12 Mar 2006 16:17:19 -0000	1.21
+++ Makefile	15 Mar 2006 00:21:34 -0000
@@ -1,5 +1,5 @@
 #CONFIG_COMPRESS=yes
-#CONFIG_ENCRYPT=yes
+CONFIG_ENCRYPT=yes
 
 CC_FLAGS=-I/usr/local/include
 LD_FLAGS=-L/usr/local/lib
@@ -69,8 +69,8 @@
 vt.o:	vt.c vt.h
 	gcc -Wall -c vt.c
 
-suspend:	md5.o encrypt.o config.o suspend.c swsusp.h config.h encrypt.h md5.h
-	gcc -Wall $(CC_FLAGS) md5.o encrypt.o config.o suspend.c -o suspend $(LD_FLAGS)
+suspend:	md5.o encrypt.o config.o suspend.c swsusp.h config.h encrypt.h md5.h s2ram.c dmidecode.c whitelist.c radeontool.c $(S2RAMOBJ)
+	gcc -g -O2 -DCONFIG_BOTH -Wall $(CC_FLAGS) md5.o encrypt.o config.o suspend.c s2ram.c -o suspend $(S2RAMOBJ) $(LD_FLAGS) -lpci 
 
 resume:	md5.o encrypt.o config.o resume.c swsusp.h config.h encrypt.h md5.h
 	gcc -Wall $(CC_FLAGS) md5.o encrypt.o config.o resume.c -static -o resume $(LD_FLAGS)
Index: s2ram.c
===================================================================
RCS file: /cvsroot/suspend/suspend/s2ram.c,v
retrieving revision 1.29
diff -u -u -r1.29 s2ram.c
--- s2ram.c	7 Mar 2006 23:54:21 -0000	1.29
+++ s2ram.c	15 Mar 2006 00:21:37 -0000
@@ -162,9 +162,11 @@
 		vbe_buffer = __save_state(&size);
 	}
 	if (flags & RADEON_OFF) {
+#if 0
 		map_radeon_cntl_mem();
 		printf("Calling radeon_cmd_light");
 		radeon_cmd_light("off");
+#endif
 	}
 }
 
@@ -237,6 +239,7 @@
 	exit(1);
 }
 
+#ifndef CONFIG_BOTH
 int main(int argc, char *argv[])
 {
 	int i;
@@ -299,3 +302,4 @@
 	s2ram_resume();
 	return i;
 }
+#endif
Index: suspend.c
===================================================================
RCS file: /cvsroot/suspend/suspend/suspend.c,v
retrieving revision 1.22
diff -u -u -r1.22 suspend.c
--- suspend.c	12 Mar 2006 16:17:19 -0000	1.22
+++ suspend.c	15 Mar 2006 00:21:48 -0000
@@ -53,6 +53,7 @@
 #define encrypt 0
 #define key_name NULL
 #endif
+static int s2ram = 1;
 
 static struct config_par parameters[PARAM_NO] = {
 	{
@@ -518,6 +519,54 @@
 						ioctl(fd, VT_WAITACTIVE, vt); \
 						ioctl(fd, KDSKBMODE, ioc2);
 
+
+static int reset_signature(int fd)
+{
+	int ret, error = 0;
+
+	printf("reseting signature...\n");
+
+	ret = lseek(fd, 0, SEEK_SET);
+	if (ret) {
+		printf("could not seek?! %m\n");
+		return -errno;
+	}
+
+	printf("reading header...\n");
+	memset(&swsusp_header, 0, sizeof(swsusp_header));
+	ret = read(fd, &swsusp_header, PAGE_SIZE);
+	if (ret == PAGE_SIZE) {
+		if (memcmp(SWSUSP_SIG, swsusp_header.sig, 10)) {
+			/* Impossible? We wrote signature and it is not there?! */
+			printf("sig not there?!!...\n");
+			return -EINVAL;
+		}
+	} else {
+		error = ret < 0 ? ret : -EIO;
+	}
+
+	if (!error || !ret) {
+		/* Reset swap signature now */
+		memcpy(swsusp_header.sig, swsusp_header.orig_sig, 10);
+		ret = lseek(fd, 0, SEEK_SET);
+		if (!ret)
+			ret = write(fd, &swsusp_header, PAGE_SIZE);
+		if (ret < (int)PAGE_SIZE) {
+			fprintf(stderr, "resume: Could not restore the partition header\n");
+			error = ret < 0 ? -errno : -EIO;
+		}
+	}
+	fsync(fd);
+	if (!error) {
+		printf("reset_signature: Signature reset ok\n");
+	} else {
+		printf("reset_signature: Error %d resetting the image. Something went very wrong please reboot machine manually, destroy saved image, and force fsck.\n"
+			"\n", error);
+		while(1);
+	}
+	return error;
+}
+
 int suspend_system(int snapshot_fd, int resume_fd, int vt_fd, int vt_no)
 {
 	loff_t avail_swap;
@@ -552,7 +601,18 @@
 				break;
 			error = write_image(snapshot_fd, resume_fd);
 			if (!error) {
-				power_off();
+				if (!s2ram)
+					power_off();
+				else {
+					//ioctl(snapshot_fd, SNAPSHOT_ENTER_ACPI_STATE, 3);
+#if 1
+					s2ram_do();
+					s2ram_resume();
+					error = EDOM;
+#endif
+					reset_signature(resume_fd);
+					break;
+				}
 			} else {
 				free_swap_pages(snapshot_fd);
 				free_snapshot(snapshot_fd);
@@ -569,6 +629,7 @@
 
 Unfreeze:
 	unfreeze(snapshot_fd);
+	/* FIXME: We have to kill the signature here */
 
 	return error;
 }
@@ -779,7 +840,6 @@
 	if (stat(resume_dev_name, &stat_buf)) {
 		fprintf(stderr, "suspend: Could not stat the resume device file\n");
 		return ENODEV;
-	} else {
 	}
 	if (!S_ISBLK(stat_buf.st_mode)) {
 		fprintf(stderr, "suspend: Invalid resume device\n");
@@ -797,6 +857,10 @@
 		ret = ENODEV;
 		goto Close_resume_fd;
 	}
+
+	if (s2ram)
+		s2ram_prepare();
+
 	if (!S_ISCHR(stat_buf.st_mode)) {
 		fprintf(stderr, "suspend: Invalid snapshot device\n");
 		ret = EINVAL;
@@ -823,6 +887,7 @@
 		goto Close_snapshot_fd;
 	}
 
+#if 0
 	sprintf(chroot_path, "/proc/%d", getpid());
 	if (chroot(chroot_path)) {
 		fprintf(stderr, "suspend: Could not chroot to %s\n", chroot_path);
@@ -830,6 +895,7 @@
 		goto Restore_console;
 	}
 	chdir("/");
+#endif
 
 	orig_loglevel = get_kernel_console_loglevel();
 	set_kernel_console_loglevel(suspend_loglevel);
Index: swsusp.h
===================================================================
RCS file: /cvsroot/suspend/suspend/swsusp.h,v
retrieving revision 1.14
diff -u -u -r1.14 swsusp.h
--- swsusp.h	12 Mar 2006 16:17:19 -0000	1.14
+++ swsusp.h	15 Mar 2006 00:21:48 -0000
@@ -25,7 +25,8 @@
 #define SNAPSHOT_GET_SWAP_PAGE		_IOR(SNAPSHOT_IOC_MAGIC, 8, void *)
 #define SNAPSHOT_FREE_SWAP_PAGES	_IO(SNAPSHOT_IOC_MAGIC, 9)
 #define SNAPSHOT_SET_SWAP_FILE		_IOW(SNAPSHOT_IOC_MAGIC, 10, unsigned int)
-#define SNAPSHOT_IOC_MAXNR	10
+#define SNAPSHOT_ENTER_ACPI_STATE	_IOR(SNAPSHOT_IOC_MAGIC, 11, int)
+#define SNAPSHOT_IOC_MAXNR	11
 
 #define	LINUX_REBOOT_MAGIC1	0xfee1dead
 #define	LINUX_REBOOT_MAGIC2	672274793
Index: whitelist.c
===================================================================
RCS file: /cvsroot/suspend/suspend/whitelist.c,v
retrieving revision 1.17
diff -u -u -r1.17 whitelist.c
--- whitelist.c	8 Mar 2006 20:55:45 -0000	1.17
+++ whitelist.c	15 Mar 2006 00:21:54 -0000
@@ -13,7 +13,7 @@
 };
 
 struct machine_entry whitelist[] = {
-	{ "IBM",			"",		"ThinkPad X32",	"", RADEON_OFF|S3_BIOS|S3_MODE },
+	//	{ "IBM",			"",		"ThinkPad X32",	"", RADEON_OFF|S3_BIOS|S3_MODE },
 	{ "Hewlett Packard",	"",	"HP OmniBook XE3 GF           ","", VBE_POST|VBE_SAVE },
 	{ "Acer            ",	"Extensa 4150                    ", "",	"", S3_BIOS|S3_MODE },
 	{ "Acer           ",	"TravelMate C300",		"",	"", VBE_SAVE },




-- 
76:        byte [] Key = new byte[ 16 ];

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: standby to disk transition

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2165 bytes --]

On Tue, 14 Mar 2006, Rafael J. Wysocki wrote:

> > The situation becomes much more problematic when the SCSI device itself is
> > powered off.  In that case (which includes the "hardware doesn't support
> > USB power during suspend" problem discussed at great length earlier), the
> > kernel has only two choices.  Either assume that the medium _has_ been
> > changed -- or more generally, that a new device is present -- or else try
> > to verify somehow that the current medium is the same as the old medium.
> > 
> > This verification can't be certain, so there would always be a chance for 
> > error.  Besides, right now the kernel contains no code for making such 
> > verifications.
> 
> The question here, as far as I understand it, is whether we can write such a
> code and, if so, whether it's worth doing.  I'm not sure of any of these now,
> but the problem is interesting. :-)

I'm pretty sure that we _can_, but it would be a fair amount of work.  
(I'm not at all sure whether it's worth doing.)

Such a verification would have to take place at several different levels.  
For instance, with a USB device:

	The USB stack would have to verify that the transport was still 
	the same (same USB descriptors);

	The SCSI stack would have to verify that the device was still the
	same (same INQUIRY data, same device type, same LUNs, same total 
	capacity);

	The gendisk driver would have to verify that the partition table
	was still the same;

	The filesystem driver would have to verify that the filesystem was
	still the same (same superblock, journal file ends in the same
	place, maybe also some other checksums of important data 
	structures).

In the end, this could affect all the transport drivers and all the
filesystem drivers.  Of course, it's not necessary to do _all_ of them --
we can be conservative and assume that the device has changed if the
necessary verification routines don't exist.

Andrew Morton pointed out that some of this work could be performed in
userspace instead of in the kernel.  It's still a lot of work, and even
just exporting to userspace the data needed for doing the checking would
be nontrivial.

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]