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
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@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@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
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@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@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@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@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@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@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@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
On Fri, 14 May 2004 lbios_kk@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
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@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
On Friday 14 May 2004 4:36 pm, lbios_kk@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.
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@Soft-Solutions.co.uk on 10 May 2004:
On Friday 14 May 2004 4:36 pm, lbios_kk@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 thelist; please don't CC me.
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
On Fri, 14 May 2004 lbios_kk@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
On Fri, 14 May 2004 lbios_kk@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@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
FYI, the Xen project is now demonstrating linux suspension under Xen.
Interesting stuff.
ron
-
Adam Sulmicki -
Antony Stone -
ebiederman＠lnxi.com -
lbios_kk＠redfenix.com -
ron minnich