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
11:11 a.m.
New subject: ARM support for CONFIG_SPARSEMEM:(was Re:DDimage)
----- 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
11:14 a.m.
New subject: ARM support for CONFIG_SPARSEMEM:(was Re:DDimage)
----- Original Message -----
> 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?
s/0xc0000000/0xd0000000/
1 p.m.
New subject: ARM support for CONFIG_SPARSEMEM:(was Re:DDimage)
On Thu, May 26, 2011 at 12:11:35PM -0400, Dave Anderson wrote:
>
> 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.
I agree. We need to start to separate different ARM platforms where normal
v<->p rules don't apply and add necessary code to perform the translations.
7:14 p.m.
New subject: ARM support for CONFIG_SPARSEMEM:(wasRe:DDimage)
I agree. We need to start to separate different ARM platforms where
normal
v<->p rules don't apply and add necessary code to perform the translations.
Thank you very much for your effort and patience. I am looking forward to see it.
There is only one question left in my mind.
Why a vmcore file with the following header is OK for crash to work fine even though the
PhysAddr is totally wrong? (I am very happy with this)
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NOTE 0x000074 0x00000000 0x00000000 0x00000 0x00000 0
LOAD 0x000074 0xc0000000 0x00000000 0x20000000 0x20000000 RWE
Takuo
>On Thu, May 26, 2011 at 12:11:35PM -0400, Dave Anderson wrote:
>>
>> >
>> > 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.
>
I agree. We need to start to separate different ARM platforms where
normal
v<->p rules don't apply and add necessary code to perform the translations.
>
>--
>Crash-utility mailing list
>Crash-utility(a)redhat.com
>https://www.redhat.com/mailman/listinfo/crash-utility
>
8:19 p.m.
New subject: ARM support for CONFIG_SPARSEMEM:(wasRe:DDimage)
----- Original Message -----
>I agree. We need to start to separate different ARM platforms
where
>normal
>v<->p rules don't apply and add necessary code to perform the
>translations.
Thank you very much for your effort and patience. I am looking forward
to see it.
There is only one question left in my mind.
Why a vmcore file with the following header is OK for crash to work
fine even though the PhysAddr is totally wrong? (I am very happy with
this)
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NOTE 0x000074 0x00000000 0x00000000 0x00000 0x00000 0
LOAD 0x000074 0xc0000000 0x00000000 0x20000000 0x20000000 RWE
Well, if the memory that is copied to the dumpfile at file offset
0x000074 is actually physical memory from 0x00200000 (instead of
physical address 0), then it's essentially working "by mistake".
Dave
Takuo
>On Thu, May 26, 2011 at 12:11:35PM -0400, Dave Anderson wrote:
>>
>> >
>> > 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.
>
>I agree. We need to start to separate different ARM platforms where
>normal
>v<->p rules don't apply and add necessary code to perform the
>translations.
>
>--
>Crash-utility mailing list
>Crash-utility(a)redhat.com
>https://www.redhat.com/mailman/listinfo/crash-utility
>
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
12:56 p.m.
New subject: ARM support for CONFIG_SPARSEMEM:(was Re:DDimage)
On Fri, May 27, 2011 at 12:37:31AM +0900, takuo.koguchi.sw(a)hitachi.com wrote:
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
Aha, now I think I know what is wrong here -- your platform is one of those
where normal v<->p translation does not apply!
And I guess VTOP/PTOV needs modification in accordance with
__phys_to_virt
and __virt_to_phys.
Yup, I think that in this case modifying VTOP/PTOV should solve the problem.
To solve this in generic way, is a bit harder. Maybe it is time to add some
platform specific code to crash which can override these kinds of things?
5271
days inactive
5272
days old
devel@lists.crash-utility.osci.io
6 comments
3 participants
participants (3)
-
Dave Anderson -
Mika Westerberg -
takuo.koguchi.sw＠hitachi.com