[PATCH] kexec: lengthen the kernel command line image

[Simon Horman]

On Mon, Mar 25, 2013 at 11:01:49PM +0800, Zhang Yanfei wrote:
> 于 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.

I would be happy to accept such a patch.