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.
