Re: [Crash-utility] ARM support for CONFIG_SPARSEMEM:(wasRe:DDimage)

>>But it only happens when I use KDUMP format instead of NETDUMP_ELF32.

Thank you forc crash-5.1.6. >But I'm thinking that if the VTOP/PTOV issue is resolved, then you won't >see that readmem() error in FILL_PTBL(), because the address that was >failing was generated by PTOV(): > > /* > * pte_offset_map(pmd, vaddr) > */ > page_table = (ulong *)PTOV(pmd_page_addr(pmd_pte)) + PTE_OFFSET(vaddr); > > FILL_PTBL(PAGEBASE(page_table), KVADDR, PAGESIZE()); With the modification of VTOP/PTOV, crash-5.1.6 recognizes "page table" of CONFIG_SPARSEMEM vmcore file and init_module_unwind_tables succeeds and backtrace command without -t option works now. But it only happens when I use KDUMP format instead of NETDUMP_ELF32. (please remember I created vmcore file from raw memory images). Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align NOTE 0x000094 0x00000000 0x00000000 0x00000 0x00000 0 LOAD 0x000094 0xc0000000 0x00200000 0xfe00000 0xfe00000 RWE 0 LOAD 0xfe00094 0xd0000000 0x40000000 0x10000000 0x10000000 RWE 0 I did not noticed that read_netdump() does not support multiple PT_LOADs for NETDUMP_ELF32 dump file format until yesterday. It seems to me that VTOP/PTOV calculation fomula can be obtained from vmcore file. Am I wrong? Best Regards, Takuo > > >----- Original Message ----- >> 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 > >Shouldn't the second PT_LOAD segment have a p_vaddr of 0xc0000000? > >Although, in the case of ARM, I believe that the p_vaddr field >is not used by the crash utility, as it is only interested in the >p_paddr and p_memsz/p_filesz fields. But I presume you meant >0xd0000000 for the second one. > >> >> And I guess VTOP/PTOV needs modification in accordance with >> __phys_to_virt and __virt_to_phys. > >Right... > >Ultimately it will be advisable to extract the ARM VTOP() and PTOV() >macros into machine-dependent functions, i.e., similar to the X86_64 >and IA64 architectures. And in those functions, intelligence will >have to be applied to determine how to handle the various ARM types. > >> >> 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. > >But I'm thinking that if the VTOP/PTOV issue is resolved, then you won't >see that readmem() error in FILL_PTBL(), because the address that was >failing was generated by PTOV(): > > /* > * pte_offset_map(pmd, vaddr) > */ > page_table = (ulong *)PTOV(pmd_page_addr(pmd_pte)) + PTE_OFFSET(vaddr); > > FILL_PTBL(PAGEBASE(page_table), KVADDR, PAGESIZE()); > >Dave > > >-- >Crash-utility mailing list &gt;Crash-utility(a)redhat.com >https://www.redhat.com/mailman/listinfo/crash-utility >