? 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