----- "Dave Anderson" <anderson(a)redhat.com&gt; 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.

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

Thanks, Dave