Re: [Fastboot] Yet another crash dump tool

[Eric W. Biederman]

Itsuro Oda <oda@xxxxxxxxxxxxx> writes:

> Hi,
> 
> On 23 Dec 2004 04:59:03 -0700
> ebiederm@xxxxxxxxxxxx (Eric W. Biederman) wrote:
> 
> > developed right now.  Would you be willing to work on the kexec system
> > call so we can get a infrastructure that reliably does what is needed
> > for everyone? 
> 
> We concentrate on the fault analysis. We think the original aim of the
> kexec (== fastboot) differ from the caputuring dump. However,
> since we apply the effort of the kexec project to mkdump, we are happy
> to return something to the kexec project. 

As a whole it has always been a goal.  The functionality was first
prototyped with kexec predecessor mcore.   At OLS this year there
appears to have been a lot of discussion the consensus reached was
that a kexec type mechanism was the way to go.  From comments Andrew
Morton has made I know it is something he would like to see.

Hariprasad Nellitheertha <hari@xxxxxxxxxx>, and Vivek Goyal
<vgoyal@xxxxxxxxxx> have recently been working on getting  the crash
dump case working.

Personally the crash dump case is not a large motivator but at the
same time I find handling the general case is quite important.
Currently I am in the process of cleaning things up and simplifying
them so hopefully we have something interesting.

> > Reading your documentation it seems to indicate that you have
> > successfully avoid using any memory that the crashing kernel used.
> > Is that correct?
> 
> No. If the code or the data structures running from crash occur to the
> mini kernel start (although it is very short) is damaged, starting the 
> mini kernel will fail.
> What we done (and will do partialy) is that the logical possibility of 
> the deadlock/hang condition is eliminated from the code running from 
> crash occur to the mini kernel start.

Let me clarify my question.

One of the problems  Hariprasad and Vivek seem to have been having is
that the keeping the crash dump kernel from using the first 1M.  You
have avoided that problem correct?

> > And just for a little active feedback.  While you safely tuck
> > your kernel away in your reserved area of memory it does not appear
> > you tuck away the data structures necessary to get there.  Which
> > makes me just a little nervous.
> 
> What do you mean "the data structures necessary to get there" ?
> The necessary information to run the mini kernel and to caputure dump 
> is stored in the reserved area at the same time of loading the mini kernel
> (during the kernel is normal).

As I recall from looking at your patch and it was obviously your last
version was that you were using kmalloc or get_free_pages for some 
of your data structures that controlled the loaded of the mini kernel
instead of allocating those data structures from the reserved area.

I'm not quite there as currently I have one structure still not
allocated in the reserved area.  But everything else is.

As soon as I can manage to focus I will have a new patch set out.

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