.....
Hi Dave,
Like Badari's issue, which actually was a non-issue, it's
difficult to debug from here.
A couple things...
When you use an additional System.map argument on the command
line, you should see the message stating that several thousand
symbol values are being changed from what is in the vmlinux file
to what is in the System.map file:
please wait... (patching ##### gdb minimal_symbol values)
This gets kicked off in the gdb_interface.c gdb_session_init() function
here:
/*
* Patch gdb's symbol values with the correct values from either
* the System.map or non-debug vmlinux, whichever is in effect.
*/
if ((pc->flags & SYSMAP) ||
(pc->namelist_debug && !pc->debuginfo_file)) {
req->command = GNU_PATCH_SYMBOL_VALUES;
req->flags = GNU_RETURN_ON_ERROR;
gdb_interface(req);
if (req->flags & GNU_COMMAND_FAILED)
error(FATAL, "patching of gdb symbol values
failed\n");
}
So, presuming that worked OK, what's strange is the read error
you get on the vmcore:
crash: read error: kernel virtual address: c00000000fa26940 type: "first vmlist addr"
The first_vmalloc_address() function is simply reading
reading the contents of the vmlist pointer, which points
to the first vm_struct in the list, and which is returning
c00000000fa26940. But then it fails to read what's in the
"addr" offset of the vm_struct at that address:
get_symbol_data("vmlist", sizeof(void *), &vmlist);
if (!readmem(vmlist+OFFSET(vm_struct_addr), KVADDR, &addr,
sizeof(void *), "first vmlist addr", RETURN_ON_ERROR))
non_matching_kernel();
Since the "addr" offset is 0, it just reads address
c00000000fa26940, which is a just a kmalloc'd unity-mapped
address.
So the question is, why is that address not capable of being
read from the vmcore? If you do a "help -n" to dump the
header contents of the vmcore, does physical address fa26940
not fit into any of the PT_LOAD segments?
(Again -- this all presumes the the "vmlist" symbol address is
correct...)
Dave
------------------------------------------------------------------------
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
crash -d 2 gave me the header..
Elf64_Phdr:
p_type: 4 (PT_NOTE)
p_offset: 288 (120)
p_vaddr: 0
p_paddr: 0
p_filesz: 1048 (418)
p_memsz: 1048 (418)
p_flags: 0 ()
p_align: 0
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_offset: 1336 (538)
p_vaddr: c000000000000000
p_paddr: 0
p_filesz: 32768 (8000)
p_memsz: 32768 (8000)
p_flags: 7 (PF_X|PF_W|PF_R)
p_align: 0
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_offset: 34104 (8538)
p_vaddr: c000000000008000
p_paddr: 8000
p_filesz: 33521663 (1ff7fff)
p_memsz: 33521663 (1ff7fff)
p_flags: 7 (PF_X|PF_W|PF_R)
p_align: 0
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_offset: 33555767 (2000537)
p_vaddr: c00000002fd0f001
p_paddr: 2fd0f001
p_filesz: 3492745215 (d02f0fff)
p_memsz: 3492745215 (d02f0fff)
p_flags: 7 (PF_X|PF_W|PF_R)
p_align: 0
Looks like that address is in a hole between PT_LOAD segments 2 and 3.
--
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA
dwilder@xxxxxxxxxx
(503)578-3789
