Linked by Thom Holwerda on Sun 4th Feb 2007 21:35 UTC, submitted by diegocg
Thread beginning with comment 209197
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.






Member since:
2005-07-08
Like Mark said, previous kernel releases needed a second kernel image in order to handle crash dumps. A bunch of releases ago, the Linux kernel added kexec, a method of loading a Linux kernel image from the running kernel and turning control over to the new kernel instance. This allowed Linux to finally have crash dump support via kdump. The new image needs to be able to dump the old kernel image, so it obviously can't be loaded into the same memory range as the old image.
The new system allows kexec to load the same kernel image into a different memory range, so you don't need to jump through hoops to get a crash dump. It would be "cooler" if Linux had dump routines that could run from within the crashing kernel, but that requires being very careful and having access to a raw block device dedicated for dumps. You can't take page faults or service interrupts from dump routines that run inside a crashing kernel, so the Linux kexec/kdump approach is a more conservative design.
I'm not completely sure if the dump image can continue to run the system after the dump. If a new production image can be loaded via kexec into the original memory range, I believe that this capability would place Linux ahead of all commercial UNIX implementations in terms of downtime due to a crash dump. Very impressive!