This is what I see using kmem -v crash> kmem -v VM_STRUCT ADDRESS RANGE SIZE c0042f80 bf000000 - bf022000 139264 de045b00 e1806000 - e1808000 8192 e09bbb40 e1808000 - e180a000 8192 e09f53c0 e180a000 - e180c000 8192 e09f5440 e180c000 - e180e000 8192 e09f58c0 e180e000 - e1810000 8192 e09f5940 e1810000 - e1812000 8192 e09f5f00 e1812000 - e1814000 8192 e09f5f80 e1814000 - e1816000 8192 ...... This is the case with modules. In an example without modules the first range is not present, so your assumption how it works is correct. One thing that could be done to get the printout less confusing is to put 0xffffffff in modules_vaddr if no modules exist (and potentially put 0 in modules_end). In arm_init in arm.c: ..... case POST_VM: machdep->machspec->vmalloc_start_addr = vt->high_memory; /* * Modules are placed in first vmalloc'd area. This is 16MB * below PAGE_OFFSET. */ machdep->machspec->modules_vaddr = first_vmalloc_address(); machdep->machspec->modules_end = machdep->kvbase - 1; if (machdep->machspec->modules_vaddr >= machdep->kvbase) { /* no modules */ /* important that modules_end < modules_vaddr to get range test right */ machdep->machspec->modules_vaddr = 0xffffffff; machdep->machspec->modules_end = 0; } To get some nicer code you can also make same changes in arm_is_module_addr. Remove local variable modules_end and use the macro MODULES_END in the return statement. Jan Jan Karlsson Senior Software Engineer MIB Sony Mobile Communications Tel: +46703062174 sonymobile.com -----Original Message----- From: crash-utility-bounces@xxxxxxxxxx [mailto:crash-utility-bounces@xxxxxxxxxx] On Behalf Of anderson@xxxxxxxxxxxx Sent: torsdag den 26 juli 2012 01:31 To: crash-utility@xxxxxxxxxx Subject: Re: Question about ARM module address range > Hi Dave > > I have taken a short look at modules_vaddr and module_end and I have > both seen relevant data: > > crash> help -m > modules_vaddr: bf000000 > modules_end: bfffffff > > and data similar to what you see. What I also have seen is that when > modules are loaded then modules_vaddr and modules_end seems correct > and when no modules have been loaded then strange values are > presented. I have looked at too few examples to be certain that this is "always" true. > > I assume (not checked in source code) that no vmalloc area is > allocated for modules if no modules are loaded. Then the function > first_vmalloc_address() will return data which is stored in > modules_vaddr but has nothing to do with this. > > So I think that the question is what values should modules_vaddr and > modules_end have if no modules are loaded. Does it matter, except that > it might be confusing for a user? Looking at arm.c where modules_vaddr > and modules_end are used, I think the code will behaves correctly (by > luck?!), also in the case of no modules. > > Jan > > Jan Karlsson > Senior Software Engineer > MIB I don't have access to my sample ARM vmcores (on vacation), but none of them have any modules loaded. So in those 3 cases, the vmalloc range starts at either d0807000 or c6024000, and so the hardwired modules_end is confusing. But it appears from your description that modules are put in a their own virtual address region from bf00000 to bffffff, whereas other vmalloc() calls generate virtual addresses above c000000? (as shown by kmem -v). In that case, you're right, the code would work as is. Anyway, it did confuse me a bit -- perhaps arm_cmd_mach() should show different "KERNEL VMALLOC BASE" and "KERNEL MODULES BASE" addresses, i.e., similar to x86_64? Dave Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility