[Crash-utility] Problem on getting kernel backtrace with a `virsh dump' dumped kvm dumpfile

[hutao at cn.fujitsu.com]

On Mon, Aug 30, 2010 at 05:00:42PM -0400, Dave Anderson wrote:
> 
> ----- "Dave Anderson" <anderson at redhat.com> wrote:
> 
> > If the backtrace above occurs with the user-space-endless-loop
> > dumpfile, then it's not necessary to send them to me.  But if the
> > bt errors still occur with the dumpfile containing the user-space
> > endless-loop (and with no System.map), then yes, I would like to
> > see the vmlinux/dumpfile pair.  (You can send the download details
> > off-list...)
> 
> Hu Tao,
> 
> I reproduced this by using the "correct" System-map file for a KVM
> guest dumpfile -- which I presume that you also did in your test 
> as well. 
> 
> Even though it is not recommended to use a System.map file as 
> a command line argument -- *unless* the vmlinux file is different
> from the kernel that caused the crash -- I was surprised that
> doing so resulted in the "bt" errors when using the "correct" 
> System.map, because the symbols that get back-patched during
> initialization would be the same values.
> 
> As it turns out, it is a bug.  However, it will only be seen if you
> use a System.map file.  Nonetheless, it should not happen when
> the System.map file matches the crashed kernel's vmlinux.
> 
> The bug is in the is_kernel_text() function, which is incorrectly
> returning TRUE on non-kernel text addresses in kernels where
> the __per_cpu_start value is no longer a large absolute value well
> beyond _etext, but changed to a low offset value.  For example, in
> older kernels, it used to be an absolute (A) value like this:
> 
>   ffffffff80419000 (A) __per_cpu_start
> 
> But in newer kernels it is zero-based (D) value:
> 
>   0 (D) __per_cpu_start
> 
> And that bug is what's causing the "bt" command to fail.
> 
> In any case, I'll fix it in the next release.

Thanks.

> 
> But -- as is always the case -- do *not* use a System.map file
> as an argument unless it is absolutely necessary!

Sure.

> 
> Thanks,
>   Dave
> 
> 
> 
>