Hibernation?

      I'm sure if someone has thought of doing this before, but I haven't found mention
of it anywhere.

Has any work been done toward the goal of "Hibernation"?  I'm writing of the
type that would use a separate partition equal to ram + swap space to store the current
memory state.  If no one has done any work to this effect, how difficult would it be?  I
may be willing to help the effort.  I've never programmed for a BIOS, but I've
done mmap() stuff before.

--Kevin

[Adam Sulmicki]

      I don't really think it is BIOS issue.

OS can do it just fine on its own. I don't see why BIOS should be invovled
here.

  Has any work been done toward the goal of
"Hibernation"?  I'm writing of
 the type that would use a separate partition equal to ram + swap space
 to store the current memory state.  If no one has done any work to this
 effect, how difficult would it be?  I may be willing to help the effort.
 I've never programmed for a BIOS, but I've done mmap() stuff before.

      If the hibernation restore occurred from the BIOS, then one wouldn't need to boot from
disk, right?  Also, if you don't need to boot from disk, the BIOS could restore the
entire memory state and then re-initialize any peripherals that need it (PCI, PCMCIA, CF,
VGA, etc.)  Should be quicker, elegant, and more effective, right?  (and OS independent if
done right.)

Question is, how much memory does LinuxBIOS use for itself?  We'd have to make sure
that it doesn't "step on its own feet" trying to get the memory state
loaded.

--Kevin

 From Adam Sulmicki <adam(a)cfar.umd.edu> on 14 May
2004:
  
 I don't really think it is BIOS issue.
 
 OS can do it just fine on its own. I don't see why BIOS should be
 invovled
 here.
 
  Has any work been done toward the goal of
"Hibernation"?  I'm writing
 of
  the type that would use a separate partition
equal to ram + swap space
 to store the current memory state.  If no one has done any work to
 this
  effect, how difficult would it be?  I may be
willing to help the
 effort.
  I've never programmed for a BIOS, but
I've done mmap() stuff before.
 
 _______________________________________________
 Linuxbios mailing list
 Linuxbios(a)clustermatic.org
 http://www.clustermatic.org/mailman/listinfo/linuxbios

[Adam Sulmicki]

      well I guess it depends on philosophy. if the idea is to have minimalistic
bios then ability to suspend doesn't belong there.

on the other hand some configurations of "bios" (where "bios" would be
the
thing in the thing in FLASH), often include linux kernel and that alone
could be re-used to enable suspend. Although the proper way to do this is
probably to use "management mode" of the recent CPUs.

On Fri, 14 May 2004 lbios_kk(a)redfenix.com wrote:

  If the hibernation restore occurred from the BIOS,
then one wouldn't need to boot from disk, right?  Also, if you don't need to boot
from disk, the BIOS could restore the entire memory state and then re-initialize any
peripherals that need it (PCI, PCMCIA, CF, VGA, etc.)  Should be quicker, elegant, and
more effective, right?  (and OS independent if done right.)

 Question is, how much memory does LinuxBIOS use for itself?  We'd have to make sure
that it doesn't "step on its own feet" trying to get the memory state
loaded.

 --Kevin

 From Adam Sulmicki <adam(a)cfar.umd.edu> on 14
May 2004:
 
 I don't really think it is BIOS issue.

 OS can do it just fine on its own. I don't see why BIOS should be
 invovled
 here.

  Has any work been done toward the goal of
"Hibernation"?  I'm writing
 of
  the type that would use a separate partition
equal to ram + swap space
 to store the current memory state.  If no one has done any work to
 this
  effect, how difficult would it be?  I may be
willing to help the
 effort.
  I've never programmed for a BIOS, but
I've done mmap() stuff before.
 _______________________________________________
 Linuxbios mailing list
 Linuxbios(a)clustermatic.org
 http://www.clustermatic.org/mailman/listinfo/linuxbios

      I'm not necessarily talking about handling a suspend or low-power mode.  I'm
talking about copying the memory to disk, then powering off.  Then, upon power-on next
time, reload the memory state, re-init peripherals and go!

So, would something like this be contained in a payload?

--Kevin

 From Adam Sulmicki <adam(a)cfar.umd.edu> on 14 May
2004:
> 
> well I guess it depends on philosophy. if the idea is to have
> minimalistic
> bios then ability to suspend doesn't belong there.
> 
> on the other hand some configurations of "bios" (where "bios"
would be
> the
> thing in the thing in FLASH), often include linux kernel and that alone
> could be re-used to enable suspend. Although the proper way to do this
> is
> probably to use "management mode" of the recent CPUs.
> 
> On Fri, 14 May 2004 lbios_kk(a)redfenix.com wrote:
> 
> > If the hibernation restore occurred from the BIOS, then one wouldn't
> need to boot from disk, right?  Also, if you don't need to boot from
> disk, the BIOS could restore the entire memory state and then
> re-initialize any peripherals that need it (PCI, PCMCIA, CF, VGA, etc.) 
> Should be quicker, elegant, and more effective, right?  (and OS
> independent if done right.)
> >
> > Question is, how much memory does LinuxBIOS use for itself?  We'd have
> to make sure that it doesn't "step on its own feet" trying to get the
> memory state loaded.
> >
> > --Kevin
> >
> >
 From Adam Sulmicki
<adam(a)cfar.umd.edu> on 14 May 2004:
> >
> > >
> > > I don't really think it is BIOS issue.
> > >
> > > OS can do it just fine on its own. I don't see why BIOS should be
> > > invovled
> > > here.
> > >
> > > > Has any work been done toward the goal of "Hibernation"? 
I'm
> writing
> > > of
> > > > the type that would use a separate partition equal to ram + swap
> space
> > > > to store the current memory state.  If no one has done any work to
> > > this
> > > > effect, how difficult would it be?  I may be willing to help the
> > > effort.
> > > > I've never programmed for a BIOS, but I've done mmap() stuff
> before.
> > >
> > > _______________________________________________
> > > Linuxbios mailing list
> > > Linuxbios(a)clustermatic.org
> > > http://www.clustermatic.org/mailman/listinfo/linuxbios
> > >
> >
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios(a)clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>

[ron minnich]

      On Fri, 14 May 2004 lbios_kk(a)redfenix.com wrote:

  So, would something like this be contained in a
payload?
you could save the entire state of the physical memeory as an elf ... 

but what about swap? Should be ok ...

ron

[Adam Sulmicki]

      also,you might want to checkout 2.6.x kernels. they seem have a good chunk
of work toward suspend-to-disk done there. so if you can put that code or
2.6.x in BIOS then you would have most of the work done for you already.

On Fri, 14 May 2004, ron minnich wrote:

  On Fri, 14 May 2004 lbios_kk(a)redfenix.com wrote:

  So, would something like this be contained in a
payload?
 you could save the entire state of the physical memeory as an elf ...

 but what about swap? Should be ok ...

 ron

[Antony Stone]

      On Friday 14 May 2004 4:36 pm, lbios_kk(a)redfenix.com wrote:

  I'm not necessarily talking about handling a
suspend or low-power mode. 
 I'm talking about copying the memory to disk, then powering off.  Then,
 upon power-on next time, reload the memory state, re-init peripherals and
 go!
I can't help feeling that it's a bit simplistic to just say "re-init 
peripherals" like that.   Some peripherals can have quite a complex state 
associated with them, and just re-initialising them as though you were 
starting from power-up may not make the O/S happy when it finds itself back 
in control after the hibernation is over?

There has to be some O/S involvement in going into, and returning from, 
hibernation mode - the question for LinuxBIOS is "how much of a task is left 
over once you take out what the Linux kernel can already do for itself?"

Regards,

Antony.

-- 
Microsoft may sell more software than any other company, but McDonald's sell 
more burgers than any other company, and I think the other similarities are 
obvious...

                                                     Please reply to the list;
                                                           please don't CC me.

      I had looked into this all before, but lost the link to the project.  I just found it
again:

http://swsusp.sourceforge.net/

The "Software Suspend" project, as they call it, handles exactly what we're
talking about, except that it occurs in the resident OS.  This means that they save only
process memory and not kernel memory states.  They also recommend for some peripheral
drivers, that one install them as modules and unload them before saving state.  They do,
however, compress the memory image and have the option of saving it in swap space.

So, in answer to your question, it may be possible to unload drivers before saving state,
then reload them upon restore.  However, this could present some difficulty if the module
is in use by a process (e.g. vga driver w/ xwindows) or in use by other modules.  This is
something that would need to be addressed.  If you have to shutdown X just to save state,
and start X again after restoring state, this wouldn't be nearly as useful.

I guess there are a few options:  Try it without re-initializing (for many, this will
work, but not all.)  Unload/load modules (good for non-critical modules)  Figure out way
to read/write state to peripheral (messy, many proprietary implementations)

One more question.  To do this effectively we'll need a hook into running a BIOS
process from inside the OS (trigger to save state and shutdown.)  How difficult is this to
do?

--Kevin

P.S. I've just subscribed to the swsusp-devel list.  I'll be asking questions in
there too.

 From Antony Stone <Antony(a)Soft-Solutions.co.uk>
on 10 May 2004:
  On Friday 14 May 2004 4:36 pm, lbios_kk(a)redfenix.com
wrote:
 
  I'm not necessarily talking about handling a
suspend or low-power
 mode. 
  I'm talking about copying the memory to disk,
then powering off.
 Then,
  upon power-on next time, reload the memory state,
re-init peripherals
 and
  go!
 
 I can't help feeling that it's a bit simplistic to just say "re-init 
 peripherals" like that.   Some peripherals can have quite a complex
 state 
 associated with them, and just re-initialising them as though you were 
 starting from power-up may not make the O/S happy when it finds itself
 back 
 in control after the hibernation is over?
 
 There has to be some O/S involvement in going into, and returning from, 
 hibernation mode - the question for LinuxBIOS is "how much of a task is
 left 
 over once you take out what the Linux kernel can already do for itself?"
 
 Regards,
 
 Antony.
 
 -- 
 Microsoft may sell more software than any other company, but McDonald's
 sell 
 more burgers than any other company, and I think the other similarities
 are 
 obvious...
 
                                                      Please reply to the
 list;
                                                            please don't
 CC me.
 
 _______________________________________________
 Linuxbios mailing list
 Linuxbios(a)clustermatic.org
 http://www.clustermatic.org/mailman/listinfo/linuxbios

[ron minnich]

      On Fri, 14 May 2004 lbios_kk(a)redfenix.com wrote:

  One more question.  To do this effectively we'll
need a hook into
 running a BIOS process from inside the OS (trigger to save state and
 shutdown.)  How difficult is this to do?
don't assume anything. 

To do this effectively you need a hook into something. Figure out what 
that thing has to do and then lets' see hwo to do it.

ron

[ron minnich]

      On Fri, 14 May 2004 lbios_kk(a)redfenix.com wrote:

  Has any work been done toward the goal of
"Hibernation"?
It would sure be nice if you would do it ... you would be very popular!

ron

      <lbios_kk(a)redfenix.com> writes:

  I'm sure if someone has thought of doing this
before, but I haven't found
 mention of it anywhere.
 
 
 Has any work been done toward the goal of "Hibernation"?  I'm writing of
the
 type that would use a separate partition equal to ram + swap space to store the
 current memory state.  If no one has done any work to this effect, how difficult
 would it be?  I may be willing to help the effort.  I've never programmed for a
 BIOS, but I've done mmap() stuff before.
For suspend to RAM there is legitimate BIOS involvement.

For all else the OS can do it.

As for the OS independence argument.  I don't see the point of
making the hardware abstraction layer hardware independent.


Eric

[ron minnich]

      FYI, the Xen project is now demonstrating linux suspension under Xen. 

Interesting stuff.

ron