Re: [PATCH 1/2] Setup min_low_pfn/max_low_pfn correctly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-- On 1/8/07, Ralf Baechle <ralf@xxxxxxxxxxxxxx> wrote:
On Mon, Jan 08, 2007 at 06:44:51PM +0100, Franck Bui-Huu wrote:

> This patch makes a better usage of these two globals.
> 'min_low_pfn' is now correctly setup for all configs, which
> allow us to rely on it in boot memory code init.


[snip]

Call Trace:
[<80109484>] dump_stack+0x8/0x34
[<80159fbc>] bad_page+0x68/0xa8
[<8015a804>] free_hot_cold_page+0x3a4/0x3b4
[<80414150>] free_all_bootmem_core+0x150/0x258
[<8040aefc>] mem_init+0x40/0x1c0
[<80400940>] start_kernel+0x2b4/0x3c8


[snip]

From a working kernel:

Determined physical RAM map:
 memory: 00001000 @ 00000000 (reserved)
 memory: 000ef000 @ 00001000 (ROM data)
 memory: 0035a000 @ 000f0000 (reserved)
 memory: 03bb6000 @ 0044a000 (usable)

So it's basically 64MB starting at physical 0.

Oh and Malta does not use CONFIG_HIGHMEM.


Yeah I just noticed that, Malta supports highmem but actually doesn't
use it.

Regarding to your mapping, usable ram starts at 0x44a000. So
min_low_pfn is now set to the corresponding pfn and the bootmem alloc
assumes it's the begining of your memory. This is done by
bootmem_init():

	bootmap_size = init_bootmem_node(NODE_DATA(0), mapstart,
                                       min_low_pfn, max_low_pfn);

However, old code always assumed that the begining of the memory was
0. That was done by:

	bootmap_size = init_bootmem(mapstart, highest);

After a while paging_init() is called which in turn calls:

	free_area_init(zones_size);

which expands to:

	free_area_init_node(0, NODE_DATA(0), zones_size,
		__pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);

In your case "__pa(PAGE_OFFSET) >> PAGE_SHIFT" results in 0 since you
haven't applied patch #2 and setup PHYS_OFFSET. So now, we're assuming
that the start of physical mem is 0 and I think it's wrong since we
previously assumed a different value.

Could you try to apply patch #2 on top of patch #1 and give it a try ?
I expect your kernel to panic in a different way. This time you should
be shooted by the following sanity check added by patch #2:

	if (min_low_pfn != ARCH_PFN_OFFSET)
		panic("PHYS_OFFSET(%lx) and your mem start(%lx) don't match",
		      PHYS_OFFSET, PFN_PHYS(min_low_pfn));

If so, could you give another try with PHYS_OFFSET defined as follow:

	#define PHYS_OFFSET	0x44a000

BTW mem_map[] size should be 32Kb smaller.

thanks,

              Franck


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux