mainline boot: 64 boots: 62 pass, 2 fail (v3.16-rc1-2-gebe0618)

[lauraa@codeaurora.org (Laura Abbott)]

On 6/26/2014 8:06 PM, Tushar Behera wrote:
> On 06/27/2014 01:12 AM, Laura Abbott wrote:
>
>>
>> +static unsigned int bank_cnt;
>> +static unsigned int max_cnt;
>> +
>>   int __init arm_add_memory(u64 start, u64 size)
>>   {
>>   	u64 aligned_start;
>>
>>   	/*
>> +	 * Some buggy bootloaders rely on the old meminfo behavior of not adding
>> +	 * more than n banks since anything past that may contain invalid data.
>> +	 */
>> +	if (bank_cnt >= max_cnt) {
>> +		pr_crit("Max banks too low, ignoring memory at 0x%08llx\n",
>> +			(long long)start);
>> +		return -EINVAL;
>> +	}
>> +
>> +	bank_cnt++;
>> +
>> +	/*
>>   	 * Ensure that start/size are aligned to a page boundary.
>>   	 * Size is appropriately rounded down, start is rounded up.
>>   	 */
>> @@ -879,6 +894,7 @@ void __init setup_arch(char **cmdline_p)
>>   		mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
>>   	machine_desc = mdesc;
>>   	machine_name = mdesc->name;
>> +	max_cnt = mdesc->bank_limit;
>
> arm_add_memory is getting called before this is being set, resulting in
> none of the memory banks getting added[1].
>
> setup_machine_fdt -> early_init_dt_scan -> early_init_dt_scan_memory
>
> Would it make sense to re-introduce the config option ARM_NR_BANKS and
> replace max_cnt with NR_BANKS?
>
> [1] http://pastebin.com/MawYD7kb
>

I was hoping to avoid re-introducing the config option but that may be
the case if we can't make the machine_info work. I'll take a better
look tomorrow.

Thanks,
Laura


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation