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

takuo.koguchi.sw at hitachi.com takuo.koguchi.sw at hitachi.com
Wed May 25 12:33:30 UTC 2011


Hi Dave,
>but the following caliculation of NR_SECTION_ROOTS() looks suspicious to me.
>#define NR_SECTION_ROOTS()	(NR_MEM_SECTIONS() / SECTIONS_PER_ROOT())
>
>Something like (((NR_MEM_SECTIONS() - 1)/ SECTIONS_PER_ROOT()) + 1) ?

Now I am quite sure the definition of NR_SECTION_ROOTS() is wrong.
In the upstream kernel, I found the following
include/linux/mmzone.h
...
994 #define SECTION_NR_TO_ROOT(sec) ((sec) / SECTIONS_PER_ROOT)
995 #define NR_SECTION_ROOTS        DIV_ROUND_UP(NR_MEM_SECTIONS, SECTIONS_PER_ROOT)
996 #define SECTION_ROOT_MASK       (SECTIONS_PER_ROOT - 1)

and
include/kernel.h DIV_ROUND_UP is defined as follows,
58 #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))

I hope you can take care of this.


By the way, I think _SECTION_SIZE_BITS issue is a separate issue.


Best Regard,

Takuo




>Thanks Dave, MW, Jan,
>
>I tried the patch which set machdep->section_size_bits and machdep->max_physmem_bits.
>
>When _SECTION_SIZE_BITS is 28, I got the following error, and failed in sparse_mem_init()
>PAGESIZE=4096
>mem_section_size = 0
>NR_SECTION_ROOTS = 0
>NR_MEM_SECTIONS = 16
>SECTIONS_PER_ROOT = 512
>SECTION_ROOT_MASK = 0x1ff
>PAGES_PER_SECTION = 65536
>crash: invalid size request: 0  type: "memory section root table"
>
>
>And when _SECTION_SIZE_BITS is 22, I got the following and sparse_mem_init() returns with out error.
>
>PAGESIZE=4096
>mem_section_size = 8
>NR_SECTION_ROOTS = 2
>NR_MEM_SECTIONS = 1024
>SECTIONS_PER_ROOT = 512
>SECTION_ROOT_MASK = 0x1ff
>PAGES_PER_SECTION = 1024
>
>... But I got another error later, which I will report later.
>
>
>In memory.c:sparse_mem_init(),
> vt->mem_sec is malloced as mem_section_size bytes block and readmem is called.
>I suppose the mem_section_size should not be zero.  I do not know _SECTION_SIZE_BITS 22 is correct or not,
>but the following caliculation of NR_SECTION_ROOTS() looks suspicious to me.
>#define NR_SECTION_ROOTS()	(NR_MEM_SECTIONS() / SECTIONS_PER_ROOT())
>
>Something like (((NR_MEM_SECTIONS() - 1)/ SECTIONS_PER_ROOT()) + 1) ?
>
>
>Best Regard,
>
>Takuo 
>
>
>
>>[ dropped my Nokia address from the CC list, since I'm not working for Nokia
>>  anymore ]
>>
>>On Tue, May 24, 2011 at 09:58:48AM -0400, Dave Anderson wrote:
>>> 
>>> BTW, I await any patches from the ARM folks to set these bits
>>> appropriately.  Currently there is this for ARM in defs.h:
>>> 
>>>   #ifdef ARM
>>>   ... [ cut ] ...
>>> 
>>>   #define _SECTION_SIZE_BITS      28
>>>   #define _MAX_PHYSMEM_BITS       32
>>> 
>>>   #endif  /* ARM */
>>> 
>>> Yet you state above that you're using 22 for _SECTION_SIZE_BITS.
>>
>>This varies between different SoCs and it is not used by others. Since it is
>>not stored in a crashdump IIRC, we really cannot set that value dynamically.
>>
>>So I see two options:
>>
>>	1) leave it as is and make crash to complain when it detects such
>>	   situation or
>>	2) guess the values and try to do the right thing (TM)
>>
>>My preference goes with 2) provided that we can get it working on majority of
>>the ARM SoCs.
>>
>>We could try to stick with _SECTION_SIZE_BITS=28, as it seems to be largest
>>currently used section size amongst different ARM SoCs, and hope that it works
>>with others where this is smaller.
>>
>>Jan, Takuo: maybe you could try whether following patch works? I don't have
>>any hardware which use SPARSEMEM so I'm unable to test it.
>>
>>Regards,
>>MW
>>
>>diff --git a/arm.c b/arm.c
>>index 0347166..9d4afcc 100644
>>--- a/arm.c
>>+++ b/arm.c
>>@@ -260,6 +260,9 @@ arm_init(int when)
>> 		    STRUCT_EXISTS("pteval_t"))
>> 			machdep->flags |= PGTABLE_V2;
>> 
>>+		machdep->section_size_bits = _SECTION_SIZE_BITS;
>>+		machdep->max_physmem_bits = _MAX_PHYSMEM_BITS;
>>+
>> 		if (symbol_exists("irq_desc"))
>> 			ARRAY_LENGTH_INIT(machdep->nr_irqs, irq_desc,
>> 					  "irq_desc", NULL, 0);
>>
>>--
>>Crash-utility mailing list
>>Crash-utility at redhat.com
>>https://www.redhat.com/mailman/listinfo/crash-utility
>>
>




More information about the Crash-utility mailing list