[PATCH] kexec: lengthen the kernel command line image

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

 



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.

-Cliff
-- 
Cliff Wickman
SGI
cpw at sgi.com
(651) 683-3824



[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