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   Sony Mobile Communications Tel: +46703062174 sonymobile.com   -----Original Message----- From: Dave Anderson [mailto:anderson@redhat.com] Sent: torsdag den 19 juli 2012 16:05 To: Discussion list for crash utility usage, maintenance and development Cc: Karlsson, Jan; Fänge, Thomas; Mika Westerberg; per fransson ml Subject: Question about ARM module address range Hi guys, While looking at the ARM per-cpu address range issue, I ran into something re: the ARM module address range values that has me confused. In arm_init(), POST_VM, you've got: machdep->machspec->modules_end = machdep->kvbase - 1; But it never gets used, because here in arm_is_module_addr() the local variable "module_end" is used instead -- although it is set to the same value: static int arm_is_module_addr(ulong vaddr) { ulong modules_start; ulong modules_end = machdep->kvbase - 1; if (!MODULES_VADDR) { /* * In case we are still initializing, and vm_init() has not been * called, we use defaults here which is 16MB below kernel start * address. */ modules_start = machdep->kvbase - 16 * 1024 * 1024; } else { modules_start = MODULES_VADDR; } return (vaddr >= modules_start && vaddr <= modules_end); } and where MODULES_VADDR is #define'd as: #define MODULES_VADDR (machdep->machspec->modules_vaddr) So given that "modules_end" is set to "machdep->kvbase - 1", and given the output from "help -m" on the 3 sample ARM dumps I have: 2.6.35: crash> help -m ... kvbase: c0000000 ... vmalloc_start_addr: d0000000 modules_vaddr: d0807000 modules_end: bfffffff kernel_text_start: c0008000 ... 2.6.36: crash> help -m ... kvbase: c0000000 ... vmalloc_start_addr: c5800000 modules_vaddr: c6024000 modules_end: bfffffff kernel_text_start: c0008000 2.6.38: crash> help -m ... kvbase: c0000000 ... vmalloc_start_addr: d0000000 modules_vaddr: d0807000 modules_end: bfffffff kernel_text_start: c0008000 ... So given that "modules_end" is always below the kvbase (bfffffff), then arm_is_module_addr() will always return FALSE -- except maybe during pre-vm_init() time when the range is temporarily set to be the "default range" between bf000000 and bfffffff. (and would there *ever* be a module in that range?) Anyway, although I don't think it's a problem, given that the only caller of arm_is_module_addr() is arm_is_vmalloc_addr(), and that function will fall through and still return TRUE if it is a module address. But it just looks strange, and at least it would seem that: (1) the machdep->machspec->modules_end version should be used, and (2) it should be updated post-vm_init() so that the arm_is_module_addr() function actually works? Or am I missing something? Dave