Mike Mason wrote: > 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" > Right (which is what the "mod" command does). > > > > > 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? That's what it looks like. This is similar in nature to the kdump discussion in this list a couple of weeks ago, where kdump creates PT_LOAD segments that are not page aligned. In this case, the phsyical memory just doesn't seem to be included at all. Note that if you go down a little farther in the "help -n" output, you'll see the ELF header contents for each PT_LOAD segment, from which the "phys_start" and "phys_end" value above are determined. The phys_start value is the PT_LOAD "p_paddr" value; the phys_end value is equal to the PT_LOAD's "p_paddr + p_memsz". Another thing of interest would be to dump the e820 map with "mach -m" and check the highest E820_RAM physical address. That should correlate with the page-shifted value of "max_mapnr". Dave
