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.
