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
