Dave Anderson wrote:
Mike Mason wrote:
I'm seeing the following warning when I run crash against a kdump vmcore
created on an i386 smp system with 4 GB RAM.
WARNING: cannot access vmalloc'd module memory
The relevant version #s are:
crash 4.0-25
kernel 2.6.16.14-6-bigsmp
crash -d2 shows the following:
crash: read error: kernel virtual address: f8c6f680 type: "module struct"
WARNING: cannot access vmalloc'd module memory
Hi Mike,
It's a read error, and given that netdump/diskdump/kdump all use the
same "read_netdump()" function, if the physical address associated
with vmalloc address f8c6f680 is not found in the vmcore file, a read
error like the above will occur.
However, that does presume that the virtual-to-physical translation
of the module's vmalloc'd address is correct. If you run crash on the
live system running that particular kernel, is module data accessible?
I don't see the warning when running crash on a live system. On a live
system, the "list modules" command shows the entire linked list. When
viewing the vmcore, I get this:
crash> list modules
c02fc354
f8c6f684
list: read error: kernel virtual address: f8c6f684 type: "list entry"
Also, if you do a "vtop f8c6f680", it will give you the physical address
that would be passed to read_netdump() to access. You can then
check that physical address against the ranges of physical memory
stored in the vmcore by doing a "help -n".
"vtop f8c6f680" shows:
VIRTUAL PHYSICAL
f8c6f680 101ede680
"help -n" shows:
vmcore_data:
flags: c0 (KDUMP_LOCAL|KDUMP_ELF64)
ndfd: 3
ofp: 8dba050
header_size: 1000
num_pt_load_segments: 4
pt_load_segment[0]:
file_offset: 3e8
phys_start: 0
phys_end: a0000
pt_load_segment[1]:
file_offset: a03e8
phys_start: 100000
phys_end: 1000000
pt_load_segment[2]:
file_offset: fa03e8
phys_start: 5000000
phys_end: 38000000
pt_load_segment[3]:
file_offset: 33fa03e8
phys_start: 38000000
phys_end: f7fed380
Is this what I should be looking for? If I'm interpreting this
correctly, the maximum phys_end (f7fed380) is less than 101ede680,
resulting in the warning. Does this mean kdump isn't capturing all of
memory in this case?
Thanks,
Mike
Dave
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
