----- Original Message -----
>
>
> ----- 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.
>
> Dave
FYI, I note you used "vtop -k" above, which I only noticed was required
yesterday when I got my first ARM modules. To address that annoyance, I've
got this fix queued for crash-6.1.5:
- Fix for the ARM "vtop" command when run on a module address. Without
the patch, the command fails with error message "vtop: ambiguous
address: <module-address> (requires -u or -k)".
(anderson@xxxxxxxxxx)
--- arm.c 22 Feb 2013 14:22:38 -0000 1.20
+++ arm.c 20 Mar 2013 16:31:58 -0000 1.21
@@ -30,6 +30,7 @@
static int arm_verify_symbol(const char *, ulong, char);
static int arm_is_module_addr(ulong);
static int arm_is_kvaddr(ulong);
+static int arm_is_uvaddr(ulong, struct task_context *);
static int arm_in_exception_text(ulong);
static int arm_in_ret_from_syscall(ulong, int *);
static void arm_back_trace(struct bt_info *);
@@ -227,7 +228,7 @@
machdep->kvbase = symbol_value("_stext") & 0xffff0000UL;
machdep->identity_map_base = machdep->kvbase;
machdep->is_kvaddr = arm_is_kvaddr;
- machdep->is_uvaddr = generic_is_uvaddr;
+ machdep->is_uvaddr = arm_is_uvaddr;
machdep->eframe_search = arm_eframe_search;
machdep->back_trace = arm_back_trace_cmd;
machdep->processor_speed = arm_processor_speed;
@@ -388,8 +389,8 @@
fprintf(fp, " dis_filter: arm_dis_filter()\n");
fprintf(fp, " cmd_mach: arm_cmd_mach()\n");
fprintf(fp, " get_smp_cpus: arm_get_smp_cpus()\n");
- fprintf(fp, " is_kvaddr: generic_is_kvaddr()\n");
- fprintf(fp, " is_uvaddr: generic_is_uvaddr()\n");
+ fprintf(fp, " is_kvaddr: arm_is_kvaddr()\n");
+ fprintf(fp, " is_uvaddr: arm_is_uvaddr()\n");
fprintf(fp, " verify_paddr: generic_verify_paddr()\n");
fprintf(fp, " show_interrupts: generic_show_interrupts()\n");
fprintf(fp, " get_irq_affinity: generic_get_irq_affinity()\n");
@@ -677,6 +678,15 @@
return (vaddr >= machdep->kvbase);
}
+static int
+arm_is_uvaddr(ulong vaddr, struct task_context *unused)
+{
+ if (arm_is_module_addr(vaddr))
+ return FALSE;
+
+ return (vaddr < machdep->kvbase);
+}
+
/*
* Returns TRUE if given pc is in exception area.
*/
But obviously the fix above does not address the correctness
of the vtop operation itself.
Dave
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
