[PATCH 5/5] kexec: X86: Pass memory ranges via e820 table instead of memmap= boot parameter

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

 



Except that is wrong. The kernel can receive more than 128 e820 entries, they just have to be passed via a different mechanism.

Thomas Renninger <trenn at suse.de> wrote:

>On Friday, April 12, 2013 05:56:08 PM Zhang Yanfei wrote:
>> ? 2013?04?11? 20:26, Thomas Renninger ??:
>> > Currently ranges are passed via kernel boot parameters:
>> > memmap=exactmap memmap=X#Y memmap=
>> > 
>...
>> > -	if (!(end - start))
>> > -		return 0;
>> > +	/*
>> > +	 * Ignore usable memory ranges for kdump kernel smaller
>> > +	 * than 100k to avoid too much ranges passed
>> > +	 * Save the new ranges (exluding lower than 100k ranges) in
>tmp_map
>> > +	 * and store the number of elements in tmp_map_ranges
>> > +	 */
>> > +	for (m = 0, i = 0; i < CRASH_MAX_MEMMAP_NR; i++) {
>> > +		unsigned long startk, endk;
>> > +		startk = (usable_mem[i].start/1024);
>> > +		endk = ((usable_mem[i].end + 1)/1024);
>> > +		if (!startk && !endk)
>> > +			/* All regions traversed. */
>> > +			break;
>> > +
>> > +		/* A region is not worth adding if region size < 100K. It eats
>> > +		 * up precious command line length. */
>> 
>> Now you are passing the e820 table directly instead of the
>commandline, so
>> does this comment make sense now?
>Yes you are right, the comment is wrong.
>It should more be like:
>/*
>A region is not worth adding if region size < 100K. e820 entries are 
>restricted to 128 in kernel, with kdump we may have to pass the one or
>other
>more and we want to try to stay at 128 max entries (from original
>table) as 
>close as possible.
>*/
>
>Thanks,
>
>      Thomas

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux