Resuming from a crashdump
dillon at apollo.backplane.com
Mon Jan 24 14:15:32 PST 2005
:I'm not interested in resuming after a real crash. The idea is
:to get suspend/resume functionality without hardware support.
:So there would be no panic, but the system would be brought to
:a halt and the memory dumped.
:> Also the devices wouldn't be in the state they had been in at
:> the time of the panic, so if you could get as far as the
:> reloaded kernel actualy doing anything, you'd either crash again
:> or risk corrupting things horribly.
:That's why they would have to be reinitialized.
It is not really doable to try to restore a kernel core dump. The
problem is that once the kernel has booted to the point where it can
check the core, it's memory will already contain hundreds if not
thousands of data structures related to booting and you can't just
overwrite them with the core image and hope that things will still work.
The phrase 'blown to smitherines' would take on new meaning :-)
For example, it would be virtually impossible to figure out which
portions of the image need to be thrown away (e.g. network
connections, device driver related allocations that have already been
done), which portions are related to device side effects and need to
be reintegrated, which portions are related to kernel stack contexts
whos memory may already be used by the boot sequence, and so forth.
It is far easier to restore a process's VM image because the image
is mostly self contained, and the restoration occurs in a context outside
of the image. The kernel doesn't work that way... there are a ton of
side effects related to device state and there is no 'outside of context'
way to do the restore. There is no convenient 'vmspace' structure for
the kernel like there is for a process.
<dillon at backplane.com>
More information about the freebsd-hackers