[PATCH] kexec: lengthen the kernel command line image

[PATCH] kexec: lengthen the kernel command line image

[Cliff Wickman]

From: Cliff Wickman <cpw@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@sgi.com>

---
 include/x86/x86-linux.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: kexec-tools-2.0.2/include/x86/x86-linux.h
===================================================================
--- kexec-tools-2.0.2.orig/include/x86/x86-linux.h
+++ kexec-tools-2.0.2/include/x86/x86-linux.h
@@ -180,7 +180,7 @@ struct x86_linux_param_header {
 	uint8_t _pad8[48];			/* 0xcd0 */
 	struct 	edd_info eddbuf[EDDMAXNR];	/* 0xd00 */
 						/* 0xeec */
-#define COMMAND_LINE_SIZE 2048
+#define COMMAND_LINE_SIZE (64*1024)
 };
 
 struct x86_linux_faked_param_header {

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] kexec: lengthen the kernel command line image

[Simon Horman]

On Mon, Feb 04, 2013 at 01:53:55PM -0600, Cliff Wickman wrote:
> From: Cliff Wickman <cpw@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@sgi.com>

Thanks, applied.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] kexec: lengthen the kernel command line image

[Zhang Yanfei]

于 2013年03月05日 09:51, Simon Horman 写道:
> On Mon, Feb 04, 2013 at 01:53:55PM -0600, Cliff Wickman wrote:
>> From: Cliff Wickman <cpw@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@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.

Thanks
Zhang

> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] kexec: lengthen the kernel command line image

[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@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@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@sgi.com
(651) 683-3824

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] kexec: lengthen the kernel command line image

[Zhang Yanfei]

于 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@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@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

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [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@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@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.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec