Suparna Bhattacharya <suparna@in.ibm.com> writes:
> On Fri, Jan 03, 2003 at 03:37:06AM -0700, Eric W. Biederman wrote:
> > Suparna Bhattacharya <suparna@in.ibm.com> writes:
> >
> > > The good news is that it worked for me. Not only that, I have just
> > > managed to get lkcd to save a dump in memory and then write it out
> > > to disk after a kexec soft boot ! I haven't tried real panic cases yet
> > > (which probably won't work rightaway :) ) and have testing and
> > > tuning to do. But kexec seems to be looking good.
> >
> > Nice. Any pointers besides lkcd.sourceforge.net
>
> I haven't posted this code to lkcd as yet - so far I'd only
> checked in the preparatory code reshuffle into lkcd cvs. There are
> still some things to improve and think about, but am planning
> to upgrade to the latest tree early next week and put things
> out, and then work on it incrementally.
O.k.
> > For the kexec on panic case there is a little code motion yet to be
> > done so that no memory allocations need to happen. The big one is
> > setting up a page table with the reboot code buffer identity mapped.
>
> I missed noticing that.
> Bootimg avoided the allocation at this stage. It did something like
> this:
>
> +static unsigned long get_identity_mapped_page(void)
> +{
> + set_pgd(pgd_offset(current->active_mm,
> + virt_to_phys(unity_page)), __pgd((_KERNPG_TABLE
> + _PAGE_PSE + (virt_to_phys(unity_page)&PGDIR_MASK))));
> + return (unsigned long)unity_page;
> +}
>
> where unity page is within directly mapped memory (not highmem).
With unity_page being allocated ahead of time...
But there is some other trick it is pulling to make certain the
intermediate page table entries are present. Spooky and I don't want
to go there.
> > I am tempted to do the identity mapping of the reboot code buffer in
> > init_mm, but for starters I will look at how complex it will be to
> > have a spare mm just sitting around for that purpose. When I get
> > to dealing with the architectures like the hammer, and the alpha where
> > you always need page tables I will need to develop an architecture
> > specific hook for building the page tables needed by the
> > code residing in the reboot code buffer, (because virtual memory
> > cannot be disabled), but that should be straight forward.
>
> A spare mm may be something which I could use for the crash dump
> pages mapping possibly simpler than the way it is maintained
> right now ... but haven't given enough thought to it yet.
Given that it is likely only to be a temporary thing I doubt it will
help. A very interesting question along those lines is how do
you get at all of the memory you are dumping, especially in PAE mode.
I have not seen the code that handles that part at all...
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jan 07 2003 - 22:00:26 EST