lkml.org 
[lkml]   [2010]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 6/6] sparc64: use early_res and nobootmem
On 03/10/2010 02:49 PM, David Miller wrote:
> From: Yinghai Lu <yinghai@kernel.org>
> Date: Wed, 10 Mar 2010 14:20:18 -0800
>
>> On 03/10/2010 02:04 PM, David Miller wrote:
>>> From: Yinghai Lu <yinghai@kernel.org>
>>> Date: Wed, 10 Mar 2010 13:24:27 -0800
>>>
>>>> use early_res/fw_memmap to replace lmb, so could use early_res replace bootme
>>>> later.
>>>>
>>>> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>>>
>>> This doesn't boot, it looks like early_res is not initialized
>>> early enough, the backtrace is:
>>>
>>> [ 0.000000] Remapping the kernel... done.
>>> [ 0.000000] Kernel panic - not syncing: can not find more space for early_res array
>>> [ 0.000000] Call Trace:
>>> [ 0.000000] [0000000000882c48] __check_and_double_early_res+0xc0/0x1c8
>>> [ 0.000000] [0000000000882f18] reserve_early+0x10/0x38
>>> [ 0.000000] [000000000087b894] prom_early_alloc+0x48/0x7c
>>> [ 0.000000] [000000000087b3e4] get_one_property+0x28/0x50
>>> [ 0.000000] [000000000087b588] prom_create_node+0x44/0xe8
>>> [ 0.000000] [000000000087b6d0] prom_build_tree+0x1c/0xac
>>> [ 0.000000] [000000000087b7b4] prom_build_devicetree+0x54/0x80
>>> [ 0.000000] [000000000087fd34] paging_init+0x69c/0x1268
>>> [ 0.000000] [00000000008786f4] start_kernel+0x88/0x374
>>> [ 0.000000] [000000000070589c] tlb_fixup_done+0x98/0xa0
>>> [ 0.000000] [0000000000000000] (null)
>>
>> looks like we need to increase MAX_EARLY_RES_X in kernel/early_res.c
>
> Ummm, hoestly, how do you know?
>
> Is there a debugging statement that triggered and printed a message
> above which told you this? No, nothing like that happened.
>
> The truth is you have no idea whatsoever because early_res has been
> written in a way that errors are hard to diagnose.
>
> It's definitely not a size issue, there are only 4 ranges that exist
> in this machine.
>
> I don't know what the actual problem is and I don't have time to debug
> it right now, please try to figure it out and send me patches to try.
>
> Actually that points out another regression of early_res, it lacks a
> "xxx=debug" command line option like LMB does, which would have
> allowed me to debug this very easily.
>
> Also, there are other problems with your changes.
>
> For example, the transformation you make in
> arch/sparc/mm/init_64.c:alloc_node_data() is absolutely not
> equivalent.
>
> NUMA nodes can have memory in discontiguous regions, the LMB node
> based allocator gets it right, whereas your code could allocate memory
> on the wrong node.
>
> Only the "nid_range()" callback passed to lmb_alloc_nid() is able to
> determine nodes properly.
>
> This is yet another regression of your early_res code.
>
> The more and more I look at the early_res code the more I see
> that:
>
> 1) LMB could do everything early_res does
>
> 2) early_res cannot do everything LMB can
>
> Can you seriously start looking at using LMB instead of this new
> stuff which seems at every element to be a step backwards?

ok. let's if we can make x86 to use lmb.

Thanks

Yinghai


\
 
 \ /
  Last update: 2010-03-11 00:09    [W:0.032 / U:11.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site