[ANNOUNCE][CFT] kexec for v2.5.48 && kexec-tools-1.7

Eric W. Biederman ebiederman at lnxi.com
Mon Nov 18 11:25:00 CET 2002


kexec is a set of systems call that allows you to load another kernel
from the currently executing Linux kernel.  The current implementation
has only been tested, and had the kinks worked out on x86, but the
generic code should work on any architecture.

Could I get some feed back on where this work and where this breaks.
With the maturation of kexec-tools to skip attempting bios calls,
I expect a new the linux kernel to load for most people.  Though I
also expect some device drivers will not reinitialize after the reboot.

The patch is archived at:
http://www.xmission.com/~ebiederm/files/kexec/

And is currently kept in two pieces.
The pure system call.
http://www.xmission.com/~ebiederm/files/kexec/linux-2.5.48.x86kexec.diff

And the set of hardware fixes known to help kexec.
http://www.xmission.com/~ebiederm/files/kexec/linux-2.5.48.x86kexec-hwfixes.diff


A compatible user space is at:
http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.7.tar.gz
This code boots either a static ELF executable or a bzImage.

As of version 1.6 /sbin/kexec now works much more like /sbin/reboot.
It is recommend you place /sbin/kexec -e in /etc/init.d/reboot
just before the the call to /sbin/reboot.  If you haven't called
/sbin/kexec previously it will fail, and you can then call
/sbin/reboot.  Given the similiarity it is now the plan to merge in
reboot via kexec into /sbin/reboot.  

One bug was fixed in the move to 2.5.48.  Previously I had failed to
clear PAE and PSE in the kernel.  This caused reboot failures when
CONFIG_HIGHMEM_64G was enabled, as the new kernel would fail when
enabling paging, as these bits remained set.  Is %cr4 present on all
386+ intel cpus, or do I need to conditionalize the code that accesses
it?

As of version 1.6 /sbin/kexec when presented with a bzImage by default
avoids all BIOS calls and jumps directly to the kernels 32 bit entry
point.  The information it would usually get from the BIOS is instead
collected from the current kernel.  Accurately getting things like
the BIOS memory map from the current kernel is a challenge, still
needs to be addressed.  Safe defaults have been provided for the cases
I do not currently have good code to gather the information from the
running kernel.

In bug reports please include the serial console output of 
kexec kexec_test.  kexec_test exercises most of the interesting code
paths that are needed to load a kernel (mainly BIOS calls) with lots
of debugging print statements, so hangs can easily be detected.   

Eric




More information about the coreboot mailing list