Hi,

Yasunori Goto <y-goto@jp.fujitsu.com> writes:

quoted text
>> This check is backwards and probably made your boot fail.
>> 
>> >> +		if (limit && limit < bdata->node_boot_start)
>> >> +			continue;
>> 
>> Changed this to break, because we don't need to search any further if
>> the current node already starts at/above the limit (remember, we walk a
>> list sorted by ->node_boot_start here).
>> 
>> I also made the checks more intuitively understandable.
>> 
>> Could you try the following fix on top of this patch?
>
> I tried it. However, my box cannot boot yet.
>
>>>  	max -= PFN_DOWN(bdata->node_boot_start);
>>>  	start -= PFN_DOWN(bdata->node_boot_start);
>>> +	fallback -= PFN_DOWN(bdata->node_boot_start);
>
> I thought this fallback was wrong at first, 
> because fallback may point 0 at this time,
> it doesn't point start_pfn of this node.
>
> But even if here is commented out, kernel can't boot up yet.

Oh, that should go out, sorry.  It is a left-over from another way to do
it.  Should pay more attention :/

quoted text
> I'd like to straggle more, but may be need more time,
> because, IA64 doesn't have early_printk, and console is not enable
> at here.....

Hm, just to make sure: this is the patch that breaks booting, right?  If
you apply all patches in the series before this one, the machine boots
fine?

Could you boot a working image with bootmem_debug in the command line?
Perhaps seeing the usual bootmem usage on this box gives a hint what is
broken.

quoted text
> P.S.
> I was very confused by local variable namimng in alloc_bootmem_core. 
> I suppose start, max, and end, should be named like
> sidx, eidx, and midx. They are not pfn, but index of bitmap.

Okay, I will make them more clear.

quoted text
> However, new_start and new_end should be named as new_start_offset and
> new_end_offset. They are not index, but offset from start address of
> the node.

Yes, that too.  I would also rename last_offset to last_eidx and
last_success to last_sidx.  What do you think?

	Hannes
--
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/