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

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

[Vivek Goyal]

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

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

[Andrew Morton]

Vivek Goyal <vgoyal@in.ibm.com> wrote:
>
>  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.

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

[Vivek Goyal]

On Mon, 2005-03-28 at 17:48 -0800, Andrew Morton wrote:
> Vivek Goyal <vgoyal@in.ibm.com> wrote:
> >
> >  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.


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.


> 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.
> 
> 
> 

Re: [Fastboot] Re: [RFC/PATCH 0/17][Kdump] Overview

[Suparna Bhattacharya]

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

On Tue, Mar 29, 2005 at 10:29:13AM +0530, Vivek Goyal wrote:
> On Mon, 2005-03-28 at 17:48 -0800, Andrew Morton wrote:
> > Vivek Goyal <vgoyal@in.ibm.com> wrote:
> > >
> > >  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.
> 
> 
> 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.
> 
> 
> > 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.
> > 
> > 
> > 
> 

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


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