[PATCH] kexec: lengthen the kernel command line image

[Zhang Yanfei]

于 2013年03月25日 20:39, Cliff Wickman 写道:
> On Mon, Mar 25, 2013 at 03:42:09PM +0800, Zhang Yanfei wrote:
>> ??? 2013???03???05??? 09:51, Simon Horman ??????:
>>> On Mon, Feb 04, 2013 at 01:53:55PM -0600, Cliff Wickman wrote:
>>>> From: Cliff Wickman <cpw at sgi.com>
>>>>
>>>> The crash kernel's boot command line is not long enough to contain the
>>>> necessary memmap= options for a large memory.
>>>>
>>>> The fix is simple, as long as the boot loader's command line is also long enough.
>>>> I'm not sure about boot loader or kernel restrictions to this length.
>>>>
>>>> Signed-off-by: Cliff Wickman <cpw at sgi.com>
>>>
>>> Thanks, applied.
>>
>> Hello
>>
>> I have a question about this patch.
>>
>> In x86 code, COMMAND_LINE_SIZE is defined as below:
>>
>> arch/x86/include/asm/setup.h
>>
>> #define COMMAND_LINE_SIZE 2048
>>
>> So even the patch lengthens the commandline length here, when reboot into
>> the new kernel, the commandline will still be stripped to 2048? right?
>>
>> So the patch seems unnecessary or unusable. Correct me if I am wrong.
> 
> You are right, we can't go beyond 2048.
> 
> We had a problem caused by the fact that the e820 table was not fully
> re-created in the crash kernel.  Without the reserved i/o spaces our
> root megaraid devices were not being discovered (we use extended PCI, and
> PCI segment 1, which seems to make that problem exclusively SGI's for now).  
> 
> My workaround at first was to pass all the i/o reservations as memmap=
> options, but that created a command line longer than 2048.  Hence this
> patch.  Then I had to amend that idea by creating a single memmap= entry that
> coalesced all reserved spaces beyond usable memory into one big reserved
> space.  I should have withdrawn the above patch when I realized that we
> cannot get around the 2048 limit.
> 
> I did not pursue the successful version of this patch however, because
> of the alternate direction being taken: that of somehow passing the entire
> e820 table to the crash kernel.  That will fix the problem we have with
> reserved i/o spaces.

So could I send a patch to revert this change? Anyway, I think we should keep the
value 2048 consistent with the kernel side.

Thanks
Zhang