Resuming from a crashdump

[João Carlos Mendes Luís]

Isn't it much easier to simply reload the full memory dump (hibernation 
file, not dump device) into RAM and continue from that point?  This 
should be done by /boot/loader, not by a full kernel, as the memory dump 
will also contain the kernel.

At this point, all you have to do is to restore the hardware state, 
which may (or may not) be just the same as recovering from suspend state.

One could flush disk cache, but this is not strictly necessary, as this 
cache will come back together in the wakeup.

Pending interrupts are a problem, but I think they could be handled just 
  like in the suspend state.

In other words, I think of a full system hibernation as a procedure like 
this:
1.1) Reserve some memory to allow space for /boot/loader in the return 
(could be always reserved?)
1.2) Start suspend procedures, leaving only the hibernation device alive
1.3) Set a flag in the loader area to say we are shutting down
1.3) Dump all memory to the hibernation device
1.4) If the loader flag is "shutdown", power off the system
1.5) If the loader flag is "wakeup", go to suspend return procedures

The restore/wakeup is like this:
2.1) /boot/loader detects the hibernation device contains valid data
2.2) Clear the shutdown flag
2.3) Instead of loading the kernel, start loading the hibernation device 
into memory
2.4) Now, do a "return from suspend" into 1.4)

It's dumb, but it's easier this way.  Now one only have to deal with 
hardware state.

Matthew Dillon wrote:
>     I think this is doable but not universal.  A kernel core dump can't be
>     used for that sort of thing (it overwrites swap and swap might contain
>     portions of the user processes in it).  
> 
>     The kernel would have to write out a special save-to-disk file containing
>     the VM image, file handles, signal state, register set, and so forth for
>     each process in the system.  Basically it would need to take DragonFly's
>     checkpointing code (as a basis), extend it suitably, and use it to dump
>     each process.
> 
>     Additional state would also have to be saved.... bound UDP sockets and
>     sockets in a LISTEN state would have to be saved and restored.  This is
>     doable.
> 
>     But the following is far more difficult:
> 
>     * tty associations		- restore
>     * tty state			- restore
>     * job control and process group state - restore
>     * open pipes		- restore
>     * open fifos		- restore
>     * open socketpairs		- restore
>     * established connections	- throw away
> 
>     And this is very difficult:
> 
>     * X windows state, established connections to X from applications, and
>       so forth.  However, it might be possible to quiece X out of its video
>       mode, remap the framebuffer, and then switch back into it.  But it
>       would still be a nasty problem.
> 
>     -
> 
>     Also, it could take just as long to restore the mess as it would just
>     to reboot normally and restart your applications.  After all, the system
>     is likely to be disk-bound either way.
> 
> 					-Matt
> 					Matthew Dillon 
> 					<dillon at backplane.com>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"


                                         Jonny

-- 
João Carlos Mendes Luís - Networking Engineer - jonny at jonny.eng.br