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

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?

On Thu, May 18, 2006 at 04:56:57PM -0700, Mike Mason wrote: > 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 > Hi Mike, This physical address is more than 4G and that's a problem in SLES10 kernels. I had posted the 64bit resources patches so that memory more than 4G is exported through /proc/iomem and kdump can capture it. These patches are still in Greg's tree and I am hoping that these will get in 2.6.18, if community likes the patches. Patchset is big and risky hence SuSE is not picking it for SLES10. Might get into SLES10 SP1. That's why you see the problem. Try booting your first kernel with mem=4G parameter and capture the dump, things should be fine. Maneesh had posted a hack patch which could be considered for inclusion in SLES10. I guess SuSE is yet to look into it. Thanks Vivek