----- Original Message ----- > Hi Dave, hi co, > > I noticed a behaviour change regarding System.map handling regarding > newer kernel like 4.14+ > > As a example: > below command works: > crash -d 1 vmlinux-4.14.43-1-pserver ps402a-30-dump.201806041421 > good.txt > > below command report error: > crash -d 1 vmlinux-4.14.43-1-pserver System.map-4.14.43-1-pserver > ps402a-30-dump.201806041421 > bad.txt > > crash: page excluded: kernel virtual address: ffffffff82237f18 type: > "page_offset_base" > > When compare the difference between good.txt and bad.txt, I noticed > following only in good.txt: > KASLR: > _stext from vmlinux-4.14.43-1-pserver: ffffffff81000000 > _stext from vmcoreinfo: ffffffff9e000000 > relocate: 1d000000 (464MB) > > I tried also on latest Ubuntu 1804, crash reports same error when run > with System.map file. > > Is this expected? First question: why are you using the System.map file as a command line argument? It only make sense to do so if vmlinux-4.14.43-1-pserver is *not* the kernel that was running when ps402a-30-dump.201806041421 was generated. Are you rebuilding a similarly-configured kernel in order to try to create something "close" to the kernel that crashed? If that's true, then that is the only reason to use the System.map file of the kernel that crashed. However... Secondly: it appears that your kernel is running with KASLR enabled and the kernel static text/data has been relocated -- where the the debug message shows that _stext has been relocated from ffffffff810000 to ffffffff9e000000. In that case, the crash utility will perform the gdb back-patching of all kernel symbols using the relocation value of 1d000000. However, if you apply the System.map file as a command line argument, it sets the symbol values back to the addresses in the System.map file, which are the original non-relocated addresses compiled into the vmlinux file. So the short answer is -- NEVER use the System.map file unless you cannot access the original vmlinux file and you are trying to simulate it by rebuilding a similarly-configured kernel. But if that is done, KASLR complicates things because the System.map file contains the non-relocated symbol values that were compiled into the vmlinux file. In that case, then I suppose you would have to create a System.map-like file *before* the kernel crashed by copying /proc/kallsyms to a "fake" System.map file. Since the relocation value changes with each boot, it's too late after the crash, and so in that case I don't have any suggestions. Just keep in mind that using a System.map file is somewhat of a desperate override, telling the crash utility to just use the symbol values within it. Dave > > Thanks, > -- > Jack Wangv > Linux Kernel Developer > > ProfitBricks GmbH > Greifswalder Str. 207 > D - 10405 Berlin > > Tel: +49 30 577 008 042 > Fax: +49 30 577 008 299 > Email: jinpu.wang@xxxxxxxxxxxxxxxx > URL: https://www.profitbricks.de > > Sitz der Gesellschaft: Berlin > Registergericht: Amtsgericht Charlottenburg, HRB 125506 B > Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph Steffens > -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
