----- Original Message -----
> On Thu, May 26, 2011 at 11:53 AM, <takuo.koguchi.sw@xxxxxxxxxxx> wrote:
> > It might come form my vmcore file's incorrectness.
> > Currently my vmcore contains the following,
> > Program Headers:
> > ÂType Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> > ÂNOTE 0x000074 0x00000000 0x00000000 0x00000 0x00000 0
> > ÂLOAD 0x000074 0xc0000000 0x00000000 0x20000000 0x20000000 RWE 0
> >
> > But actual mapping is,
> > Virtual 0xc0000000-0xcfffffff corresponds Physical 0x00000000-0x0fffffff
> > and
> > Virtual 0xd0000000-0xdfffffff corresponds Physical 0x40000000-0x4fffffff
> >
> > Then I tried to prepend the following header instead,
> > Program Headers:
> > ÂType Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> > ÂNOTE 0x000094 0x00000000 0x00000000 0x00000 0x00000 0
> > ÂLOAD 0x000094 0xc0000000 0x00000000 0x10000000 0x10000000 RWE 0
> > ÂLOAD 0x10000094 0xd0000000 0x40000000 0x10000000 0x10000000 RWE 0
> >
> > This time crash does not recognize the vmcore file.
> >
> > Perhaps I have to change VTOP/PTOV macros accordingly?
>
> It should be enough if you have machdep->machspec->phys_base set to
> correct value, which is 0 in your case. You can see this by running
> 'crash -d1 ...'. Also if possible, can you post the full output here
> so that we can analyze it further.
Hey guys,
Pardon my confusion/interruption, but the "actual mapping" above would
be unique for unity-mapping. The 0xc0000000-0xcfffffff segment is
"traditionally" unity-mapped, where VTOP() would strip off the kvbase,
and then apply a physical base if appropriate. But then the second
0xd0000000-0xdfffffff segment could not use the same logic.
Looking at the upstream ARM sources, __pa() is:
#define __pa(x) __virt_to_phys((unsigned long)(x))
where __virt_to_phys() does something different if CONFIG_ARM_PATCH_PHYS_VIRT
is configured:
#ifdef CONFIG_ARM_PATCH_PHYS_VIRT
/*
* Constants used to force the right instruction encodings and shifts
* so that all we need to do is modify the 8-bit constant field.
*/
#define __PV_BITS_31_24 0x81000000
#define __PV_BITS_23_16 0x00810000
extern unsigned long __pv_phys_offset;
#define PHYS_OFFSET __pv_phys_offset
#define __pv_stub(from,to,instr,type) \
__asm__("@ __pv_stub\n" \
"1: " instr " %0, %1, %2\n" \
" .pushsection .pv_table,\"a\"\n" \
" .long 1b\n" \
" .popsection\n" \
: "=r" (to) \
: "r" (from), "I" (type))
static inline unsigned long __virt_to_phys(unsigned long x)
{
unsigned long t;
__pv_stub(x, t, "add", __PV_BITS_31_24);
#ifdef CONFIG_ARM_PATCH_PHYS_VIRT_16BIT
__pv_stub(t, t, "add", __PV_BITS_23_16);
#endif
return t;
}
static inline unsigned long __phys_to_virt(unsigned long x)
{
unsigned long t;
__pv_stub(x, t, "sub", __PV_BITS_31_24);
#ifdef CONFIG_ARM_PATCH_PHYS_VIRT_16BIT
__pv_stub(t, t, "sub", __PV_BITS_23_16);
#endif
return t;
}
#else
#define __virt_to_phys(x) ((x) - PAGE_OFFSET + PHYS_OFFSET)
#define __phys_to_virt(x) ((x) - PHYS_OFFSET + PAGE_OFFSET)
#endif
Is that what's happening here? I don't understand the __pv_stub()
stuff, but if the virtual-to-physical unity-mapping is as Takuo
described, then there would have to be a change to the ARM VTOP/PTOV
macros.
Anyway, as to why crash doesn't recognize the vmcore with the second
PT_LOAD segment added, you'll have to debug why is_netdump() is
rejecting it.
Dave
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
