On Tue, Apr 15, 2008 at 6:02 PM, Ingo Molnar <mingo@elte.hu> wrote:
quoted text
>
>  * Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>
>  > On Tue, Apr 15, 2008 at 5:44 PM, Ingo Molnar <mingo@elte.hu> wrote:
>  > >
>  > >  * Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>  > >
>  > >  > >  +       unsigned long max_arch_pfn = 1ULL << (MAX_PHYSMEM_BITS-PAGE_SHIFT);
>  > >  > >
>  > >  > >  and also check my analysis whether it is correct and whether it
>  > >  > >  matches the reported bug patterns. But otherwise the fix looks like
>  > >  > >  a safe fix for v2.6.25-final to me - it only filters out values
>  > >  > >  from sparsemem input that are nonsensical in the sparsemem
>  > >  > >  framework anyway.
>  > >  >
>  > >
>  > > > can you check why find_max_pfn() e820_32.c need to call
>  > >  > memory_present? wonder if it can be removed.
>  > >
>  > >  this is the only call to memory_present() we do in 32-bit arch setup, so
>  > >  it's required.
>  > >
>  > >  (the function find_max_pfn() is woefully misnamed, but that's a cleanup
>  > >  - i just fixed this in x86.git.)
>  >
>  > 64 bit is calling that via paging_init
>  > ==>sparse_memory_present_with_active_regions(MAX_NUMNODES).
>  >
>  > and
>  > void __init sparse_memory_present_with_active_regions(int nid)
>
>  yeah - 64-bit is different here and it's not affected by the problem
>  because there SECTION_SIZE_BITS is 27 (==128 MB chunks),
>  MAX_PHYSADDR_BITS is 40 (== 1 TB) - giving 8192 section map entries.
>  Once larger than 1 TB 64-bit x86 systems are created MAX_PHYSADDR_BITS
>  needs to be increased.

also 64 bit
early_node_map[10] active PFN ranges
    0:        0 ->      149
    0:      256 ->   917408
    0:  1048576 ->  8519680
    1:  8519680 -> 16908288
    2: 16908288 -> 25296896
    3: 25296896 -> 33685504
    4: 33685504 -> 42074112
    5: 42074112 -> 50462720
    6: 50462720 -> 58851328
    7: 58851328 -> 67239936

and 32 bit only has one entry
[    0.000000] early_node_map[1] active PFN ranges
[    0.000000]     0:        0 ->  1048576

YH
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/