* [PATCH] kexec: lengthen the kernel command line image
@ 2013-02-04 19:53 Cliff Wickman
2013-03-05 1:51 ` Simon Horman
0 siblings, 1 reply; 6+ messages in thread
From: Cliff Wickman @ 2013-02-04 19:53 UTC (permalink / raw)
To: kexec
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] kexec: lengthen the kernel command line image 2013-02-04 19:53 [PATCH] kexec: lengthen the kernel command line image Cliff Wickman @ 2013-03-05 1:51 ` Simon Horman 2013-03-25 7:42 ` Zhang Yanfei 0 siblings, 1 reply; 6+ messages in thread From: Simon Horman @ 2013-03-05 1:51 UTC (permalink / raw) To: Cliff Wickman; +Cc: kexec 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] kexec: lengthen the kernel command line image 2013-03-05 1:51 ` Simon Horman @ 2013-03-25 7:42 ` Zhang Yanfei 2013-03-25 12:39 ` Cliff Wickman 0 siblings, 1 reply; 6+ messages in thread From: Zhang Yanfei @ 2013-03-25 7:42 UTC (permalink / raw) To: Simon Horman; +Cc: kexec, Cliff Wickman 于 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] kexec: lengthen the kernel command line image 2013-03-25 7:42 ` Zhang Yanfei @ 2013-03-25 12:39 ` Cliff Wickman 2013-03-25 15:01 ` Zhang Yanfei 0 siblings, 1 reply; 6+ messages in thread From: Cliff Wickman @ 2013-03-25 12:39 UTC (permalink / raw) To: Zhang Yanfei; +Cc: Simon Horman, kexec 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] kexec: lengthen the kernel command line image 2013-03-25 12:39 ` Cliff Wickman @ 2013-03-25 15:01 ` Zhang Yanfei 2013-03-27 12:24 ` Simon Horman 0 siblings, 1 reply; 6+ messages in thread From: Zhang Yanfei @ 2013-03-25 15:01 UTC (permalink / raw) To: Cliff Wickman; +Cc: kexec, Simon Horman, 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] kexec: lengthen the kernel command line image 2013-03-25 15:01 ` Zhang Yanfei @ 2013-03-27 12:24 ` Simon Horman 0 siblings, 0 replies; 6+ messages in thread From: Simon Horman @ 2013-03-27 12:24 UTC (permalink / raw) To: Zhang Yanfei; +Cc: kexec, Zhang Yanfei, Cliff Wickman 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-03-27 12:24 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-02-04 19:53 [PATCH] kexec: lengthen the kernel command line image Cliff Wickman 2013-03-05 1:51 ` Simon Horman 2013-03-25 7:42 ` Zhang Yanfei 2013-03-25 12:39 ` Cliff Wickman 2013-03-25 15:01 ` Zhang Yanfei 2013-03-27 12:24 ` Simon Horman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox