[RFC/PATCH 0/17][Kdump] Overview

Discussion:

(too old to reply)

Vivek Goyal

2005-03-28 13:29:09 UTC

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

Andrew Morton

2005-03-29 01:51:29 UTC

Permalink

Post by Vivek Goyal
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

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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

Vivek Goyal

2005-03-29 05:01:46 UTC

Permalink

Post by Andrew Morton

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

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.

Post by Andrew Morton
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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

Suparna Bhattacharya

2005-03-29 08:34:58 UTC

Permalink

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

Post by Vivek Goyal

Post by Andrew Morton

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

_______________________________________________
fastboot mailing list
http://lists.osdl.org/mailman/listinfo/fastboot

--
Suparna Bhattacharya (***@in.ibm.com)
Linux Technology Center
IBM Software Lab, India

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------