> 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