Overview

Hi,

This patchset restores back the kdump functionality on i386. Patchset contains the patches for user space (kexec-tools-1.101) and kernel space (2.6.12-rc1-mm3). Some of the user space patches are being released for the completeness.

This patch set performs following.

kexec-tool-1.101
(http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.101.tar.gz)
-----------------------------------------------------------------------

- Create a backup region and copy the first 640K of memory to backup region over a crash.
- Generate Elf headers representing crashed memory and store in reserved region. Also appends the memmap= and elfcorehdr= parameters to command line internally to be passed to capture kernel.
- Fills in the virtual addresses for linearly mapped region at the elf header creation time. This assists in limited debugging through gdb.
- Adds another command line option "--crash-dump" to differentiate between kexec on panic and kexec on panic with crash dump on.

2.6.12-rc1-mm3
--------------

- Retrieve physical address of elf core headers, stored by crashed kernel.
- Export dump image in ELF format through /proc/vmcore interface.
- Export raw dump image through /dev/oldmem interface.

Following patches (as in series file) need to be dropped before applying the fresh ones.

crashdump-documentation.patch crashdump-memory-preserving-reboot-using-kexec.patch crashdump-routines-for-copying-dump-pages.patch crashdump-routines-for-copying-dump-pages-fixes.patch crashdump-elf-format-dump-file-access.patch crashdump-linear-raw-format-dump-file-access.patch crashdump-linear-raw-format-dump-file-access-coding-style.patch

I look forward for comments and suggestions. I have done basic testing on uni and SMP systems.

Thanks
Vivek

At some point we should stop tossing out patches and replacing them in this manner.

Because doing so makes it hard for people to see what has changed.

It makes it hard for people to see that changes in the above patches haven't been simply lost.

And the fact that you were probably working against some kernel other than -mm gives little confidence that the kdump development team have been testing the patches which are presently in -mm. And that is what they are there for.

Andrew, I shall take care of sending incremental patches only next time onwards. The reason why I did this because changes were relatively large and I thought dropping the existing series and replacing it with new series (some patches retaining the old name) might be a better idea.

Vivek, perhaps a little more context about the background of the changes would have helped here. Not everyone has been following the details of fastboot/kdump discussion for the last few months.

Let me give this a try - Eric/Vivek please pitch in and correct me, where I go wrong since even I haven't been that tightly plugged in all the time.

Sometime back kexec underwent a major redesign in some respect. This was mainly in terms of the division of responsibilities between the kernel and user-space kexec-tools. For kdump in particular this also had to do with the real groundwork being set for better integration into kexec mainstream, and a more reliable and cleaner interface between what happens in kexec-tools, in the old kernel's context and in the new kernel's context. On the whole, a better world for all :)

However, at that time, when this new revamped kexec was integrated into -mm, the corresponding kdump redesign was still pending -- which is why the *old* crash dump patches in -mm were kind of irrelevant and broken because they hadn't caught up with the kexec revamp. Which is also why kdump wasn't being tested on -mm ... it didn't even work !

Sorting this all out is really what I see Vivek's latest patches being intended for -- and I believe it is the outcome of the work that has been happening on fastboot over the last several months ? This is why, I guess, it made sense for him to take the route of throwing out most of the old patches and starting afresh with new ones, because these are *built* on a different foundation altogether, so incremental patches would have been rather confusing.

This should not be a continuing trend from here on (I hope not at least, since major revamps are quite costly on stability !), so shouldn't be a cause for worry. The bullet has been bitten. From here on, changes must be incremental.

Regards
Suparna

Suparna Bhattacharya ([email protected])
Linux Technology Center
IBM Software Lab, India