10:37 a.m.
Dave, Mika,
memory.h I am using is probably the same as this,
https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=blob;f=arch...
19 /* physical offset of RAM */
20 #define PHYS_OFFSET UL(CONFIG_PHYS_OFFSET) <-- 0x00200000
21
22 #define MAX_PHYSMEM_BITS 32
23 #define SECTION_SIZE_BITS 28
24
25 /* Certain configurations of MSM7x30 have multiple memory banks.
26 * One or more of these banks can contain holes in the memory map as well.
27 * These macros define appropriate conversion routines between the physical
28 * and virtual address domains for supporting these configurations using
29 * SPARSEMEM and a 3G/1G VM split.
30 */
31
32 #if defined(CONFIG_ARCH_MSM7X30)
33
34 #define EBI0_PHYS_OFFSET PHYS_OFFSET
35 #define EBI0_PAGE_OFFSET PAGE_OFFSET
36 #define EBI0_SIZE 0x10000000
37
38 #define EBI1_PHYS_OFFSET 0x40000000
39 #define EBI1_PAGE_OFFSET (EBI0_PAGE_OFFSET + EBI0_SIZE)
40
41 #if (defined(CONFIG_SPARSEMEM) && defined(CONFIG_VMSPLIT_3G))
42
43 #define __phys_to_virt(phys) \
44 ((phys) >= EBI1_PHYS_OFFSET ? \
45 (phys) - EBI1_PHYS_OFFSET + EBI1_PAGE_OFFSET : \
46 (phys) - EBI0_PHYS_OFFSET + EBI0_PAGE_OFFSET)
47
48 #define __virt_to_phys(virt) \
49 ((virt) >= EBI1_PAGE_OFFSET ? \
50 (virt) - EBI1_PAGE_OFFSET + EBI1_PHYS_OFFSET : \
51 (virt) - EBI0_PAGE_OFFSET + EBI0_PHYS_OFFSET)
52
53 #endif
54
55 #endif
So my previous description of actual memory mapping was not correct.
The correct description is,
Virtual 0xc0000000-0xcfdfffff -> Physical 0x00200000-0x0fffffff
and
Virtual 0xd0000000-0xdfffffff -> Physical 0x40000000-0x4fffffff
Tomorrow I will check if vmcore with the following header is recognized by crash.
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NOTE 0x000094 0x00000000 0x00000000 0x00000 0x00000 0
LOAD 0x000094 0xc0000000 0x00200000 0x0fe00000 0x0fe00000 RWE
LOAD 0x0fe00094 0xc0000000 0x40000000 0x10000000 0x10000000 RWE
And I guess VTOP/PTOV needs modification in accordance with __phys_to_virt and
__virt_to_phys.
For your information,
The vmcore file with the following header is recognized by crash and many commands works
fine,
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NOTE 0x000074 0x00000000 0x00000000 0x00000 0x00000 0
LOAD 0x000074 0xc0000000 0x00000000 0x20000000 0x20000000 RWE
if the patches for unwind_arm.c, arm.c and defs.h posted in this ML thread applied and
readmem error_handle for FILL_PTBL is change to RETURN_ON_ERROR.
Without the last modification above crash exits when readmem fails at FILL_PTBL before
reaching the first prompt.
Best Regards,
Takuo Koguchi
----- Original Message -----
> On Thu, May 26, 2011 at 11:53 AM, <takuo.koguchi.sw(a)hitachi.com> 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(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility