[Crash-utility] Re: crash enhancements proposal

Dave Anderson anderson at redhat.com
Mon May 8 14:06:17 UTC 2006


Castor Fu wrote:

> On Fri, 5 May 2006, Dave Anderson wrote:
>
> > Michael Holzheu wrote:
> >
> >>
> >> So I think for very complex installations, there are
> >> cases, where it makes sense to just snapshot the
> >> whole system with a crash dump.
> >>
> >> But I still think, it is best to just add an elf core command
> >> to crash and do the rest of user space debugging with gdb...
> >>
> >> Michael
> >>
> >
> > But like you also mentioned, there's the extra burden of
> > potentially having to save the swap partition contents
> > someplace?
> >
> > That seems kind of ugly...
>
> We actually use the user space function from lcrash quite
> frequently at 3PAR.  Much of our code lives in user space,
> but we try to ensure that critical processes never swap,
> so we generally don't mind not having the swap space.
>
> Our situation is pretty specialized, but probably pretty
> common with embedded servers...

Hey Castor,

Nice to hear from an really old crash contributor!

I mean in terms of crash's 7-year lifespan -- I don't know
whether you're a boarder or a greybeard...

Anyway, thinking about this gain, this kind of crash extension
does seem reasonable.  You've got all the information you need
readily available; just doing a "vm -p" shows you where everything is.

That is of course if kexec/kdump doesn't trash the current
task's pgd.  Although I wasn't aware that it even did so,
this recent thread on the fastboot list highlighted that issue:


> On Mon, May 01, 2006 at 06:49:16PM +0900, Magnus Damm wrote:
> > kexec: Avoid overwriting the current pgd (i386)
> >
> > This patch upgrades the i386-specific kexec code to avoid overwriting the
> > current pgd. Overwriting the current pgd is bad when CONFIG_CRASH_DUMP is used
> > to start a secondary kernel that dumps the memory of the previous kernel.
> >
> > The code introduces a new set of page tables called "page_table_a". These
> > tables are used to provide an executable identity mapping without overwriting
> > the current pgd.
>
> True, current pgd is overwritten but that effects only user space mappings
> and currently "crash" supports only backtracing kernel space code. But at
> the same time probably it is not a bad idea to maintain a separate page
> table and switch to that instead of overwriting the existing pgd. This
> shall help if in future user space backtracing is also supported.
>
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20060508/71f5a8b2/attachment.htm>


More information about the Crash-utility mailing list