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/arm/mach-msm/include/mach/memory.h;h=afe6051b9826d788849aafa52b55b3760b6cf1ec;hb=debd216b762a87da0faf0eb4f991ed10c7a052cc 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@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 >
-- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
