[Crash-utility] ARM support for CONFIG_SPARSEMEM:(wasRe:DDimage)
Toshikazu Nakayama
nakayama.ts at ncos.nec.co.jp
Tue Jun 21 10:51:47 UTC 2011
>>>> But it only happens when I use KDUMP format instead of NETDUMP_ELF32.
> I cannot reconfirm this. Please forget about it.
> I forgot to mention one thing. I had to remove the following line from symbol.c as my target is non-SMP
> 1413: lm->mod_percpu = ULONG(modbuf + OFFSET(module_percpu));
> I hope you will find a better way.
>
> Best Regards,
>
> Takuo
I'm sorry about making trouble.
Attachment is my proposal fix.
Thanks,
Toshi.
>
>> 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/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
>>>
>>> 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
>>> Crash-utility at redhat.com
>>> https://www.redhat.com/mailman/listinfo/crash-utility
>>>
>>
>
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mod_percpu-fix-non-SMP.patch
Type: text/x-patch
Size: 1021 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20110621/c7e25500/attachment.bin>
More information about the Crash-utility
mailing list