<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Castor Fu wrote:
<blockquote TYPE=CITE>On Fri, 5 May 2006, Dave Anderson wrote:
<p>> Michael Holzheu wrote:
<br>>
<br>>>
<br>>> So I think for very complex installations, there are
<br>>> cases, where it makes sense to just snapshot the
<br>>> whole system with a crash dump.
<br>>>
<br>>> But I still think, it is best to just add an elf core command
<br>>> to crash and do the rest of user space debugging with gdb...
<br>>>
<br>>> Michael
<br>>>
<br>>
<br>> But like you also mentioned, there's the extra burden of
<br>> potentially having to save the swap partition contents
<br>> someplace?
<br>>
<br>> That seems kind of ugly...
<p>We actually use the user space function from lcrash quite
<br>frequently at 3PAR.  Much of our code lives in user space,
<br>but we try to ensure that critical processes never swap,
<br>so we generally don't mind not having the swap space.
<p>Our situation is pretty specialized, but probably pretty
<br><tt>common with embedded servers...</tt></blockquote>
<tt>Hey Castor,</tt><tt></tt>
<p><tt>Nice to hear from an really old crash contributor!</tt><tt></tt>
<p><tt>I mean in terms of crash's 7-year lifespan -- I don't know</tt>
<br><tt>whether you're a boarder or a greybeard...</tt><tt></tt>
<p><tt>Anyway, thinking about this gain, this kind of crash extension</tt>
<br><tt>does seem reasonable.  You've got all the information you
need</tt>
<br><tt>readily available; just doing a "vm -p" shows you where everything
is.</tt><tt></tt>
<p><tt>That is of course if kexec/kdump doesn't trash the current</tt>
<br><tt>task's pgd.  Although I wasn't aware that it even did so,</tt>
<br><tt>this recent thread on the fastboot list highlighted that issue:</tt>
<br><tt></tt> 
<blockquote TYPE=CITE>
<pre>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.
</pre>
</blockquote>

<p><tt>Dave</tt></html>