On Thu, Mar 21, 2013 at 11:04:16AM -0400, Dave Anderson wrote: > > > ----- Original Message ----- > > > After your fix, the module could show module address now. > > However I don't know whether this showing is correct or not... > > For while I want to check the module's defined global variant like > > below, I just find it is not being mapped yet... > > But this variant definition is very straightforward, like: > > int cctdev_major = 0; > > > > > > crash> sym cctdev_major > > bf16564d (B) cctdev_major > > crash> vtop -k bf16564d > > VIRTUAL PHYSICAL > > bf16564d (not mapped) > > > > PAGE DIRECTORY: c0004000 > > PGD: c0006fc4 => 1f3cdc11 > > PMD: c0006fc4 => 1f3cdc11 > > PTE: 1f3cd594 => 0 > > > > I don't know what is going wrong there, and I am planning to manually > > print out symbols' address before trigger the dump, and to see > > whether they could be aligned. > > > > Do you have some better idea how to fix it?... > > No, not really, I'm not an ARM guy... > > But it's possible/probable that the "vtop" translation on kernel module > virtual (vmalloc) addresses may not be working correctly. I also noted > yesterday that "vtop" on user-space virtual addresses fails pretty miserably > most of the time. Both arm_kvtop() and arm_uvtop() both end up calling the > common arm_vtop() function, so I'm guessing that it's the culprit. AFAICT, arm_uvtop() should do the translation depending whether the address falls to the kernel virtual address or userspace. There's a check: if (is_kernel_thread(tc->task) && IS_KVADDR(uvaddr)) and I believe that IS_KVADDR() is enough here as it checks both the module and kernel virtual memory limits. I asked Luc whether he could provide his last file set to me as well. Hope they will shed some light into this. Dave, Are you able to access module symbols on ARM dump (the one that Luc provided)? Or is it failing completely? -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
