[Crash-utility] WARNING: cannot access vmalloc'd module memory

[Dave Anderson]

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