On Mon, Aug 30, 2010 at 05:00:42PM -0400, Dave Anderson wrote: > > ----- "Dave Anderson" <anderson@xxxxxxxxxx> 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 > > > > -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
