Re: [Fastboot] [PATCH] free initrds boot option
In message <[EMAIL PROTECTED]> you wrote: > On Wed, Dec 13, 2006 at 10:35:08AM +0900, Horms wrote: > > On Fri, Dec 08, 2006 at 10:32:15AM +1100, Michael Neuling wrote: > > > > >Is there a kexec-tools patch too? How does second kernel know about > > > > >the location of the first kernel's initrd to be reused? > > > > > > > > > > > > > > kexec-tools has to be modified to pass the first kernel initrd. On > > > > powerpc, initrd locations are exported using device-tree. At present, > > > > kexec-tool ignores the first kernel initrd property values and creates > > > > new initrd properties if the user passes '--initrd' option to the kexec > > > > command. So, will be an issue unless first kernel device-tree is passed > > > > as buffer. > > > > > > We've been using the --devicetreeblob kexec-tools option available for > > > POWERPC. This enables you to setup the device tree (and hence, the > > > initrd points) as you like. > > > > > > I'm happy to put together a patch for kexec-tools. > > > > Please do. And please cc me on a copy that applies against kexec-tools-test ing. > > > > > Unfortunately this > > > is arch specific. A quick look through the x86, ia64, s390 and ppc64 > > > code shows the --initrd option for all these just reads the specified > > > initrd file, pushes it out to memory and uses the base and size pointers > > > to setup the next boot. We'd obviously just skip to the last stage. > > > > > > So what's the kexec-tools option called? --initrd-location ? > > > > That sounds fine to me. I think its ok to make it arch specific for > > starters and then move it out to generic code later. That said, if > > you're feeling particularly entergetic, feel free to do the generic > > stuff now and just add null stubs for the other architectures (does > > that makes sense?). > > Did anything ever come of this? Not yet, but it's on my todo list. Mikey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] [PATCH] free initrds boot option
On Wed, Dec 13, 2006 at 10:35:08AM +0900, Horms wrote: > On Fri, Dec 08, 2006 at 10:32:15AM +1100, Michael Neuling wrote: > > > >Is there a kexec-tools patch too? How does second kernel know about > > > >the location of the first kernel's initrd to be reused? > > > > > > > > > > > kexec-tools has to be modified to pass the first kernel initrd. On > > > powerpc, initrd locations are exported using device-tree. At present, > > > kexec-tool ignores the first kernel initrd property values and creates > > > new initrd properties if the user passes '--initrd' option to the kexec > > > command. So, will be an issue unless first kernel device-tree is passed > > > as buffer. > > > > We've been using the --devicetreeblob kexec-tools option available for > > POWERPC. This enables you to setup the device tree (and hence, the > > initrd points) as you like. > > > > I'm happy to put together a patch for kexec-tools. > > Please do. And please cc me on a copy that applies against > kexec-tools-testing. > > > Unfortunately this > > is arch specific. A quick look through the x86, ia64, s390 and ppc64 > > code shows the --initrd option for all these just reads the specified > > initrd file, pushes it out to memory and uses the base and size pointers > > to setup the next boot. We'd obviously just skip to the last stage. > > > > So what's the kexec-tools option called? --initrd-location ? > > That sounds fine to me. I think its ok to make it arch specific for > starters and then move it out to generic code later. That said, if > you're feeling particularly entergetic, feel free to do the generic > stuff now and just add null stubs for the other architectures (does > that makes sense?). Did anything ever come of this? -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] [PATCH] free initrds boot option
On Wed, Dec 13, 2006 at 10:35:08AM +0900, Horms wrote: On Fri, Dec 08, 2006 at 10:32:15AM +1100, Michael Neuling wrote: Is there a kexec-tools patch too? How does second kernel know about the location of the first kernel's initrd to be reused? kexec-tools has to be modified to pass the first kernel initrd. On powerpc, initrd locations are exported using device-tree. At present, kexec-tool ignores the first kernel initrd property values and creates new initrd properties if the user passes '--initrd' option to the kexec command. So, will be an issue unless first kernel device-tree is passed as buffer. We've been using the --devicetreeblob kexec-tools option available for POWERPC. This enables you to setup the device tree (and hence, the initrd points) as you like. I'm happy to put together a patch for kexec-tools. Please do. And please cc me on a copy that applies against kexec-tools-testing. Unfortunately this is arch specific. A quick look through the x86, ia64, s390 and ppc64 code shows the --initrd option for all these just reads the specified initrd file, pushes it out to memory and uses the base and size pointers to setup the next boot. We'd obviously just skip to the last stage. So what's the kexec-tools option called? --initrd-location base size? That sounds fine to me. I think its ok to make it arch specific for starters and then move it out to generic code later. That said, if you're feeling particularly entergetic, feel free to do the generic stuff now and just add null stubs for the other architectures (does that makes sense?). Did anything ever come of this? -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] [PATCH] free initrds boot option
In message [EMAIL PROTECTED] you wrote: On Wed, Dec 13, 2006 at 10:35:08AM +0900, Horms wrote: On Fri, Dec 08, 2006 at 10:32:15AM +1100, Michael Neuling wrote: Is there a kexec-tools patch too? How does second kernel know about the location of the first kernel's initrd to be reused? kexec-tools has to be modified to pass the first kernel initrd. On powerpc, initrd locations are exported using device-tree. At present, kexec-tool ignores the first kernel initrd property values and creates new initrd properties if the user passes '--initrd' option to the kexec command. So, will be an issue unless first kernel device-tree is passed as buffer. We've been using the --devicetreeblob kexec-tools option available for POWERPC. This enables you to setup the device tree (and hence, the initrd points) as you like. I'm happy to put together a patch for kexec-tools. Please do. And please cc me on a copy that applies against kexec-tools-test ing. Unfortunately this is arch specific. A quick look through the x86, ia64, s390 and ppc64 code shows the --initrd option for all these just reads the specified initrd file, pushes it out to memory and uses the base and size pointers to setup the next boot. We'd obviously just skip to the last stage. So what's the kexec-tools option called? --initrd-location base size ? That sounds fine to me. I think its ok to make it arch specific for starters and then move it out to generic code later. That said, if you're feeling particularly entergetic, feel free to do the generic stuff now and just add null stubs for the other architectures (does that makes sense?). Did anything ever come of this? Not yet, but it's on my todo list. Mikey - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] [PATCH] free initrds boot option
On Fri, Dec 08, 2006 at 10:32:15AM +1100, Michael Neuling wrote: > > >Is there a kexec-tools patch too? How does second kernel know about > > >the location of the first kernel's initrd to be reused? > > > > > > > > kexec-tools has to be modified to pass the first kernel initrd. On > > powerpc, initrd locations are exported using device-tree. At present, > > kexec-tool ignores the first kernel initrd property values and creates > > new initrd properties if the user passes '--initrd' option to the kexec > > command. So, will be an issue unless first kernel device-tree is passed > > as buffer. > > We've been using the --devicetreeblob kexec-tools option available for > POWERPC. This enables you to setup the device tree (and hence, the > initrd points) as you like. > > I'm happy to put together a patch for kexec-tools. Please do. And please cc me on a copy that applies against kexec-tools-testing. > Unfortunately this > is arch specific. A quick look through the x86, ia64, s390 and ppc64 > code shows the --initrd option for all these just reads the specified > initrd file, pushes it out to memory and uses the base and size pointers > to setup the next boot. We'd obviously just skip to the last stage. > > So what's the kexec-tools option called? --initrd-location ? That sounds fine to me. I think its ok to make it arch specific for starters and then move it out to generic code later. That said, if you're feeling particularly entergetic, feel free to do the generic stuff now and just add null stubs for the other architectures (does that makes sense?). -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] [PATCH] free initrds boot option
On Fri, Dec 08, 2006 at 10:32:15AM +1100, Michael Neuling wrote: Is there a kexec-tools patch too? How does second kernel know about the location of the first kernel's initrd to be reused? kexec-tools has to be modified to pass the first kernel initrd. On powerpc, initrd locations are exported using device-tree. At present, kexec-tool ignores the first kernel initrd property values and creates new initrd properties if the user passes '--initrd' option to the kexec command. So, will be an issue unless first kernel device-tree is passed as buffer. We've been using the --devicetreeblob kexec-tools option available for POWERPC. This enables you to setup the device tree (and hence, the initrd points) as you like. I'm happy to put together a patch for kexec-tools. Please do. And please cc me on a copy that applies against kexec-tools-testing. Unfortunately this is arch specific. A quick look through the x86, ia64, s390 and ppc64 code shows the --initrd option for all these just reads the specified initrd file, pushes it out to memory and uses the base and size pointers to setup the next boot. We'd obviously just skip to the last stage. So what's the kexec-tools option called? --initrd-location base size? That sounds fine to me. I think its ok to make it arch specific for starters and then move it out to generic code later. That said, if you're feeling particularly entergetic, feel free to do the generic stuff now and just add null stubs for the other architectures (does that makes sense?). -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] free initrds boot option
> >Is there a kexec-tools patch too? How does second kernel know about > >the location of the first kernel's initrd to be reused? > > > > > kexec-tools has to be modified to pass the first kernel initrd. On > powerpc, initrd locations are exported using device-tree. At present, > kexec-tool ignores the first kernel initrd property values and creates > new initrd properties if the user passes '--initrd' option to the kexec > command. So, will be an issue unless first kernel device-tree is passed > as buffer. We've been using the --devicetreeblob kexec-tools option available for POWERPC. This enables you to setup the device tree (and hence, the initrd points) as you like. I'm happy to put together a patch for kexec-tools. Unfortunately this is arch specific. A quick look through the x86, ia64, s390 and ppc64 code shows the --initrd option for all these just reads the specified initrd file, pushes it out to memory and uses the base and size pointers to setup the next boot. We'd obviously just skip to the last stage. So what's the kexec-tools option called? --initrd-location ? (BTW I'm offline soon, so I probably won't get to this for a few weeks) > Initrd memory can be excluded like other segments such as RTAS and TCE > on powerpc. However it is not implemented yet even on powerpc and is > an issue on other archs. The above should allow us to do these checks in kexec-tools. Mikey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] [PATCH] free initrds boot option
Vivek Goyal wrote: On Thu, Dec 07, 2006 at 02:36:18PM +1100, Michael Neuling wrote: I would have to agree with this; it also seems a bit odd to me to have this at all (kexec provides a new kernel image, surely it also provides a new initrd image???) Yes, kexec provides the option --initrd, so that a user can supply an initrd image to be loaded along with kernel. The first boot will need to hold a copy of the in memory fs for the second boot. This image can be large (much larger than the kernel), hence we can save time when the memory loader is slow. Also, it reduces the memory footprint while extracting the first boot since you don't need another copy of the fs. Is there a kexec-tools patch too? How does second kernel know about the location of the first kernel's initrd to be reused? kexec-tools has to be modified to pass the first kernel initrd. On powerpc, initrd locations are exported using device-tree. At present, kexec-tool ignores the first kernel initrd property values and creates new initrd properties if the user passes '--initrd' option to the kexec command. So, will be an issue unless first kernel device-tree is passed as buffer. In general kexec can overwrite all the previous kernel's memory. It just knows about the segments the user has passed to it and it will place these segments to their destination locations. There are no gurantees that in this process some data from first kernel will not be overwritten. So it might not be a very safe scheme. Initrd memory can be excluded like other segments such as RTAS and TCE on powerpc. However it is not implemented yet even on powerpc and is an issue on other archs. Thanks Haren Thanks Vivek ___ fastboot mailing list fastboot@lists.osdl.org https://lists.osdl.org/mailman/listinfo/fastboot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] [PATCH] free initrds boot option
On Thu, Dec 07, 2006 at 02:36:18PM +1100, Michael Neuling wrote: > > I would have to agree with this; it also seems a bit odd to me to have > > this at all (kexec provides a new kernel image, surely it also > > provides a new initrd image???) > Yes, kexec provides the option --initrd, so that a user can supply an initrd image to be loaded along with kernel. > The first boot will need to hold a copy of the in memory fs for the > second boot. This image can be large (much larger than the kernel), > hence we can save time when the memory loader is slow. Also, it reduces > the memory footprint while extracting the first boot since you don't > need another copy of the fs. > Is there a kexec-tools patch too? How does second kernel know about the location of the first kernel's initrd to be reused? In general kexec can overwrite all the previous kernel's memory. It just knows about the segments the user has passed to it and it will place these segments to their destination locations. There are no gurantees that in this process some data from first kernel will not be overwritten. So it might not be a very safe scheme. Thanks Vivek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] [PATCH] free initrds boot option
Vivek Goyal wrote: On Thu, Dec 07, 2006 at 02:36:18PM +1100, Michael Neuling wrote: I would have to agree with this; it also seems a bit odd to me to have this at all (kexec provides a new kernel image, surely it also provides a new initrd image???) Yes, kexec provides the option --initrd, so that a user can supply an initrd image to be loaded along with kernel. The first boot will need to hold a copy of the in memory fs for the second boot. This image can be large (much larger than the kernel), hence we can save time when the memory loader is slow. Also, it reduces the memory footprint while extracting the first boot since you don't need another copy of the fs. Is there a kexec-tools patch too? How does second kernel know about the location of the first kernel's initrd to be reused? kexec-tools has to be modified to pass the first kernel initrd. On powerpc, initrd locations are exported using device-tree. At present, kexec-tool ignores the first kernel initrd property values and creates new initrd properties if the user passes '--initrd' option to the kexec command. So, will be an issue unless first kernel device-tree is passed as buffer. In general kexec can overwrite all the previous kernel's memory. It just knows about the segments the user has passed to it and it will place these segments to their destination locations. There are no gurantees that in this process some data from first kernel will not be overwritten. So it might not be a very safe scheme. Initrd memory can be excluded like other segments such as RTAS and TCE on powerpc. However it is not implemented yet even on powerpc and is an issue on other archs. Thanks Haren Thanks Vivek ___ fastboot mailing list fastboot@lists.osdl.org https://lists.osdl.org/mailman/listinfo/fastboot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] free initrds boot option
Is there a kexec-tools patch too? How does second kernel know about the location of the first kernel's initrd to be reused? kexec-tools has to be modified to pass the first kernel initrd. On powerpc, initrd locations are exported using device-tree. At present, kexec-tool ignores the first kernel initrd property values and creates new initrd properties if the user passes '--initrd' option to the kexec command. So, will be an issue unless first kernel device-tree is passed as buffer. We've been using the --devicetreeblob kexec-tools option available for POWERPC. This enables you to setup the device tree (and hence, the initrd points) as you like. I'm happy to put together a patch for kexec-tools. Unfortunately this is arch specific. A quick look through the x86, ia64, s390 and ppc64 code shows the --initrd option for all these just reads the specified initrd file, pushes it out to memory and uses the base and size pointers to setup the next boot. We'd obviously just skip to the last stage. So what's the kexec-tools option called? --initrd-location base size? (BTW I'm offline soon, so I probably won't get to this for a few weeks) Initrd memory can be excluded like other segments such as RTAS and TCE on powerpc. However it is not implemented yet even on powerpc and is an issue on other archs. The above should allow us to do these checks in kexec-tools. Mikey - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] free initrds boot option
On Thu, 07 Dec 2006 14:42:57 +1100 Michael Neuling wrote:
> Index: linux-2.6-ozlabs/init/initramfs.c
> ===
> --- linux-2.6-ozlabs.orig/init/initramfs.c
> +++ linux-2.6-ozlabs/init/initramfs.c
> @@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
> return message;
> }
>
> +static int do_retain_initrd = 0;
Don't init that to 0. That's done for us and it's a bit
wasteful in the object file(s), so we try not to do that.
> +static int __init retain_initrd_param(char *str)
> +{
> + if (*str)
> + return 0;
> + do_retain_initrd = 1;
> + return 1;
> +}
> +__setup("retain_initrd", retain_initrd_param);
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] free initrds boot option
On Thu, 07 Dec 2006 14:42:57 +1100 Michael Neuling wrote:
> Add retain_initrd option to control freeing of initrd memory after
> extraction. By default, free memory as previously.
>
> Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
> ---
> Updated based on comments from akpm.
> Added documentation and changed option name to "retain_initrd"
> Tested on POWERPC with CPIOs
>
> Documentation/kernel-parameters.txt |2 ++
> init/initramfs.c| 18 --
> 2 files changed, 18 insertions(+), 2 deletions(-)
>
> Index: linux-2.6-ozlabs/init/initramfs.c
> ===
> --- linux-2.6-ozlabs.orig/init/initramfs.c
> +++ linux-2.6-ozlabs/init/initramfs.c
> @@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
> return message;
> }
>
> +static int do_retain_initrd = 0;
> +
> +static int __init retain_initrd_param(char *str)
> +{
> + if (*str)
> + return 0;
> + do_retain_initrd = 1;
> + return 1;
> +}
> +__setup("retain_initrd", retain_initrd_param);
> +
> extern char __initramfs_start[], __initramfs_end[];
> #ifdef CONFIG_BLK_DEV_INITRD
> #include
> @@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr
>
> static void __init free_initrd(void)
> {
> -#ifdef CONFIG_KEXEC
> unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
> unsigned long crashk_end = (unsigned long)__va(crashk_res.end);
How does this work when CONFIG_KEXEC=n ??
Tested?
> + if (do_retain_initrd)
> + goto skip;
> +
> +#ifdef CONFIG_KEXEC
> /*
>* If the initrd region is overlapped with crashkernel reserved region,
>* free only memory that is not part of crashkernel region.
> @@ -515,7 +529,7 @@ static void __init free_initrd(void)
> } else
> #endif
> free_initrd_mem(initrd_start, initrd_end);
> -
> +skip:
> initrd_start = 0;
> initrd_end = 0;
> }
> -
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] free initrds boot option
Michael Neuling wrote:
Add free_initrd= option to control freeing of initrd memory after
extraction. By default, free memory as previously.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
Useful for kexec when you want to reuse the same initrd. Testing on
POWERPC with CPIOs
This option (free_initrd) will not work if the user loads the kdump
kernel and does the normal kexec boot later on powerpc. The reason is
initrd will be loaded by yaboot at 36MB and kdump image at 32M (Right
now it is fixed). It could be possible that we will end up overwriting
initrd.
init/initramfs.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
Index: linux-2.6-ozlabs/init/initramfs.c
===
--- linux-2.6-ozlabs.orig/init/initramfs.c
+++ linux-2.6-ozlabs/init/initramfs.c
@@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
return message;
}
+static int do_free_initrd = 1;
+
+int __init free_initrd_param(char *p)
+{
+ if (p && strncmp(p, "0", 1) == 0)
+ do_free_initrd = 0;
+
+ return 0;
+}
+early_param("free_initrd", free_initrd_param);
+
extern char __initramfs_start[], __initramfs_end[];
#ifdef CONFIG_BLK_DEV_INITRD
#include
@@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr
static void __init free_initrd(void)
{
-#ifdef CONFIG_KEXEC
unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
unsigned long crashk_end = (unsigned long)__va(crashk_res.end);
+ if (!do_free_initrd)
+ goto skip;
+
+#ifdef CONFIG_KEXEC
/*
* If the initrd region is overlapped with crashkernel reserved region,
* free only memory that is not part of crashkernel region.
@@ -515,7 +529,7 @@ static void __init free_initrd(void)
} else
#endif
free_initrd_mem(initrd_start, initrd_end);
-
+skip:
initrd_start = 0;
initrd_end = 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] free initrds boot option
Add retain_initrd option to control freeing of initrd memory after
extraction. By default, free memory as previously.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
Updated based on comments from akpm.
Added documentation and changed option name to "retain_initrd"
Tested on POWERPC with CPIOs
Documentation/kernel-parameters.txt |2 ++
init/initramfs.c| 18 --
2 files changed, 18 insertions(+), 2 deletions(-)
Index: linux-2.6-ozlabs/Documentation/kernel-parameters.txt
===
--- linux-2.6-ozlabs.orig/Documentation/kernel-parameters.txt
+++ linux-2.6-ozlabs/Documentation/kernel-parameters.txt
@@ -1366,6 +1366,8 @@ and is between 256 and 4096 characters.
resume= [SWSUSP]
Specify the partition device for software suspend
+ retain_initrd [RAM] Keep initrd memory after extraction
+
rhash_entries= [KNL,NET]
Set number of hash buckets for route cache
Index: linux-2.6-ozlabs/init/initramfs.c
===
--- linux-2.6-ozlabs.orig/init/initramfs.c
+++ linux-2.6-ozlabs/init/initramfs.c
@@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
return message;
}
+static int do_retain_initrd = 0;
+
+static int __init retain_initrd_param(char *str)
+{
+ if (*str)
+ return 0;
+ do_retain_initrd = 1;
+ return 1;
+}
+__setup("retain_initrd", retain_initrd_param);
+
extern char __initramfs_start[], __initramfs_end[];
#ifdef CONFIG_BLK_DEV_INITRD
#include
@@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr
static void __init free_initrd(void)
{
-#ifdef CONFIG_KEXEC
unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
unsigned long crashk_end = (unsigned long)__va(crashk_res.end);
+ if (do_retain_initrd)
+ goto skip;
+
+#ifdef CONFIG_KEXEC
/*
* If the initrd region is overlapped with crashkernel reserved region,
* free only memory that is not part of crashkernel region.
@@ -515,7 +529,7 @@ static void __init free_initrd(void)
} else
#endif
free_initrd_mem(initrd_start, initrd_end);
-
+skip:
initrd_start = 0;
initrd_end = 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] free initrds boot option
> I would have to agree with this; it also seems a bit odd to me to have > this at all (kexec provides a new kernel image, surely it also > provides a new initrd image???) The first boot will need to hold a copy of the in memory fs for the second boot. This image can be large (much larger than the kernel), hence we can save time when the memory loader is slow. Also, it reduces the memory footprint while extracting the first boot since you don't need another copy of the fs. New patch on it's way. Mikey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] free initrds boot option
Andrew Morton wrote: I'd have thought that an option `retain_initrd' would make more sense. Please always update Documentation/kernel-parameters.txt when adding boot options. I would have to agree with this; it also seems a bit odd to me to have this at all (kexec provides a new kernel image, surely it also provides a new initrd image???) -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] free initrds boot option
On Thu, 07 Dec 2006 11:18:43 +1100
Michael Neuling <[EMAIL PROTECTED]> wrote:
> Add free_initrd= option to control freeing of initrd memory after
> extraction. By default, free memory as previously.
>
> Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
> ---
> Useful for kexec when you want to reuse the same initrd. Testing on
> POWERPC with CPIOs
>
> --- linux-2.6-ozlabs.orig/init/initramfs.c
> +++ linux-2.6-ozlabs/init/initramfs.c
> @@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
> return message;
> }
>
> +static int do_free_initrd = 1;
> +
> +int __init free_initrd_param(char *p)
> +{
> + if (p && strncmp(p, "0", 1) == 0)
> + do_free_initrd = 0;
> +
> + return 0;
> +}
> +early_param("free_initrd", free_initrd_param);
> +
> extern char __initramfs_start[], __initramfs_end[];
> #ifdef CONFIG_BLK_DEV_INITRD
> #include
> @@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr
>
> static void __init free_initrd(void)
> {
> -#ifdef CONFIG_KEXEC
> unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
> unsigned long crashk_end = (unsigned long)__va(crashk_res.end);
>
> + if (!do_free_initrd)
> + goto skip;
> +
> +#ifdef CONFIG_KEXEC
> /*
>* If the initrd region is overlapped with crashkernel reserved region,
>* free only memory that is not part of crashkernel region.
> @@ -515,7 +529,7 @@ static void __init free_initrd(void)
> } else
> #endif
> free_initrd_mem(initrd_start, initrd_end);
> -
> +skip:
> initrd_start = 0;
> initrd_end = 0;
> }
I'd have thought that an option `retain_initrd' would make more sense.
Please always update Documentation/kernel-parameters.txt when adding boot
options.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] free initrds boot option
On Thu, 07 Dec 2006 11:18:43 +1100 Michael Neuling wrote:
> Add free_initrd= option to control freeing of initrd memory after
> extraction. By default, free memory as previously.
Please add doc. for this in Documentation/kernel-parameters.txt.
> Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
> ---
> Useful for kexec when you want to reuse the same initrd. Testing on
> POWERPC with CPIOs
>
> init/initramfs.c | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> Index: linux-2.6-ozlabs/init/initramfs.c
> ===
> --- linux-2.6-ozlabs.orig/init/initramfs.c
> +++ linux-2.6-ozlabs/init/initramfs.c
> @@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
> return message;
> }
>
> +static int do_free_initrd = 1;
> +
> +int __init free_initrd_param(char *p)
> +{
> + if (p && strncmp(p, "0", 1) == 0)
> + do_free_initrd = 0;
> +
> + return 0;
> +}
> +early_param("free_initrd", free_initrd_param);
> +
> extern char __initramfs_start[], __initramfs_end[];
> #ifdef CONFIG_BLK_DEV_INITRD
> #include
> @@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr
>
> static void __init free_initrd(void)
> {
> -#ifdef CONFIG_KEXEC
> unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
> unsigned long crashk_end = (unsigned long)__va(crashk_res.end);
>
> + if (!do_free_initrd)
> + goto skip;
> +
> +#ifdef CONFIG_KEXEC
> /*
>* If the initrd region is overlapped with crashkernel reserved region,
>* free only memory that is not part of crashkernel region.
> @@ -515,7 +529,7 @@ static void __init free_initrd(void)
> } else
> #endif
> free_initrd_mem(initrd_start, initrd_end);
> -
> +skip:
> initrd_start = 0;
> initrd_end = 0;
> }
> -
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] free initrds boot option
Add free_initrd= option to control freeing of initrd memory after
extraction. By default, free memory as previously.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
Useful for kexec when you want to reuse the same initrd. Testing on
POWERPC with CPIOs
init/initramfs.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
Index: linux-2.6-ozlabs/init/initramfs.c
===
--- linux-2.6-ozlabs.orig/init/initramfs.c
+++ linux-2.6-ozlabs/init/initramfs.c
@@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
return message;
}
+static int do_free_initrd = 1;
+
+int __init free_initrd_param(char *p)
+{
+ if (p && strncmp(p, "0", 1) == 0)
+ do_free_initrd = 0;
+
+ return 0;
+}
+early_param("free_initrd", free_initrd_param);
+
extern char __initramfs_start[], __initramfs_end[];
#ifdef CONFIG_BLK_DEV_INITRD
#include
@@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr
static void __init free_initrd(void)
{
-#ifdef CONFIG_KEXEC
unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
unsigned long crashk_end = (unsigned long)__va(crashk_res.end);
+ if (!do_free_initrd)
+ goto skip;
+
+#ifdef CONFIG_KEXEC
/*
* If the initrd region is overlapped with crashkernel reserved region,
* free only memory that is not part of crashkernel region.
@@ -515,7 +529,7 @@ static void __init free_initrd(void)
} else
#endif
free_initrd_mem(initrd_start, initrd_end);
-
+skip:
initrd_start = 0;
initrd_end = 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] free initrds boot option
Add free_initrd= option to control freeing of initrd memory after
extraction. By default, free memory as previously.
Signed-off-by: Michael Neuling [EMAIL PROTECTED]
---
Useful for kexec when you want to reuse the same initrd. Testing on
POWERPC with CPIOs
init/initramfs.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
Index: linux-2.6-ozlabs/init/initramfs.c
===
--- linux-2.6-ozlabs.orig/init/initramfs.c
+++ linux-2.6-ozlabs/init/initramfs.c
@@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
return message;
}
+static int do_free_initrd = 1;
+
+int __init free_initrd_param(char *p)
+{
+ if (p strncmp(p, 0, 1) == 0)
+ do_free_initrd = 0;
+
+ return 0;
+}
+early_param(free_initrd, free_initrd_param);
+
extern char __initramfs_start[], __initramfs_end[];
#ifdef CONFIG_BLK_DEV_INITRD
#include linux/initrd.h
@@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr
static void __init free_initrd(void)
{
-#ifdef CONFIG_KEXEC
unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
unsigned long crashk_end = (unsigned long)__va(crashk_res.end);
+ if (!do_free_initrd)
+ goto skip;
+
+#ifdef CONFIG_KEXEC
/*
* If the initrd region is overlapped with crashkernel reserved region,
* free only memory that is not part of crashkernel region.
@@ -515,7 +529,7 @@ static void __init free_initrd(void)
} else
#endif
free_initrd_mem(initrd_start, initrd_end);
-
+skip:
initrd_start = 0;
initrd_end = 0;
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] free initrds boot option
On Thu, 07 Dec 2006 11:18:43 +1100 Michael Neuling wrote:
Add free_initrd= option to control freeing of initrd memory after
extraction. By default, free memory as previously.
Please add doc. for this in Documentation/kernel-parameters.txt.
Signed-off-by: Michael Neuling [EMAIL PROTECTED]
---
Useful for kexec when you want to reuse the same initrd. Testing on
POWERPC with CPIOs
init/initramfs.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
Index: linux-2.6-ozlabs/init/initramfs.c
===
--- linux-2.6-ozlabs.orig/init/initramfs.c
+++ linux-2.6-ozlabs/init/initramfs.c
@@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
return message;
}
+static int do_free_initrd = 1;
+
+int __init free_initrd_param(char *p)
+{
+ if (p strncmp(p, 0, 1) == 0)
+ do_free_initrd = 0;
+
+ return 0;
+}
+early_param(free_initrd, free_initrd_param);
+
extern char __initramfs_start[], __initramfs_end[];
#ifdef CONFIG_BLK_DEV_INITRD
#include linux/initrd.h
@@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr
static void __init free_initrd(void)
{
-#ifdef CONFIG_KEXEC
unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
unsigned long crashk_end = (unsigned long)__va(crashk_res.end);
+ if (!do_free_initrd)
+ goto skip;
+
+#ifdef CONFIG_KEXEC
/*
* If the initrd region is overlapped with crashkernel reserved region,
* free only memory that is not part of crashkernel region.
@@ -515,7 +529,7 @@ static void __init free_initrd(void)
} else
#endif
free_initrd_mem(initrd_start, initrd_end);
-
+skip:
initrd_start = 0;
initrd_end = 0;
}
-
---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] free initrds boot option
Add retain_initrd option to control freeing of initrd memory after
extraction. By default, free memory as previously.
Signed-off-by: Michael Neuling [EMAIL PROTECTED]
---
Updated based on comments from akpm.
Added documentation and changed option name to retain_initrd
Tested on POWERPC with CPIOs
Documentation/kernel-parameters.txt |2 ++
init/initramfs.c| 18 --
2 files changed, 18 insertions(+), 2 deletions(-)
Index: linux-2.6-ozlabs/Documentation/kernel-parameters.txt
===
--- linux-2.6-ozlabs.orig/Documentation/kernel-parameters.txt
+++ linux-2.6-ozlabs/Documentation/kernel-parameters.txt
@@ -1366,6 +1366,8 @@ and is between 256 and 4096 characters.
resume= [SWSUSP]
Specify the partition device for software suspend
+ retain_initrd [RAM] Keep initrd memory after extraction
+
rhash_entries= [KNL,NET]
Set number of hash buckets for route cache
Index: linux-2.6-ozlabs/init/initramfs.c
===
--- linux-2.6-ozlabs.orig/init/initramfs.c
+++ linux-2.6-ozlabs/init/initramfs.c
@@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
return message;
}
+static int do_retain_initrd = 0;
+
+static int __init retain_initrd_param(char *str)
+{
+ if (*str)
+ return 0;
+ do_retain_initrd = 1;
+ return 1;
+}
+__setup(retain_initrd, retain_initrd_param);
+
extern char __initramfs_start[], __initramfs_end[];
#ifdef CONFIG_BLK_DEV_INITRD
#include linux/initrd.h
@@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr
static void __init free_initrd(void)
{
-#ifdef CONFIG_KEXEC
unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
unsigned long crashk_end = (unsigned long)__va(crashk_res.end);
+ if (do_retain_initrd)
+ goto skip;
+
+#ifdef CONFIG_KEXEC
/*
* If the initrd region is overlapped with crashkernel reserved region,
* free only memory that is not part of crashkernel region.
@@ -515,7 +529,7 @@ static void __init free_initrd(void)
} else
#endif
free_initrd_mem(initrd_start, initrd_end);
-
+skip:
initrd_start = 0;
initrd_end = 0;
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] free initrds boot option
On Thu, 07 Dec 2006 14:42:57 +1100 Michael Neuling wrote:
Add retain_initrd option to control freeing of initrd memory after
extraction. By default, free memory as previously.
Signed-off-by: Michael Neuling [EMAIL PROTECTED]
---
Updated based on comments from akpm.
Added documentation and changed option name to retain_initrd
Tested on POWERPC with CPIOs
Documentation/kernel-parameters.txt |2 ++
init/initramfs.c| 18 --
2 files changed, 18 insertions(+), 2 deletions(-)
Index: linux-2.6-ozlabs/init/initramfs.c
===
--- linux-2.6-ozlabs.orig/init/initramfs.c
+++ linux-2.6-ozlabs/init/initramfs.c
@@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
return message;
}
+static int do_retain_initrd = 0;
+
+static int __init retain_initrd_param(char *str)
+{
+ if (*str)
+ return 0;
+ do_retain_initrd = 1;
+ return 1;
+}
+__setup(retain_initrd, retain_initrd_param);
+
extern char __initramfs_start[], __initramfs_end[];
#ifdef CONFIG_BLK_DEV_INITRD
#include linux/initrd.h
@@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr
static void __init free_initrd(void)
{
-#ifdef CONFIG_KEXEC
unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
unsigned long crashk_end = (unsigned long)__va(crashk_res.end);
How does this work when CONFIG_KEXEC=n ??
Tested?
+ if (do_retain_initrd)
+ goto skip;
+
+#ifdef CONFIG_KEXEC
/*
* If the initrd region is overlapped with crashkernel reserved region,
* free only memory that is not part of crashkernel region.
@@ -515,7 +529,7 @@ static void __init free_initrd(void)
} else
#endif
free_initrd_mem(initrd_start, initrd_end);
-
+skip:
initrd_start = 0;
initrd_end = 0;
}
-
---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] free initrds boot option
On Thu, 07 Dec 2006 14:42:57 +1100 Michael Neuling wrote:
Index: linux-2.6-ozlabs/init/initramfs.c
===
--- linux-2.6-ozlabs.orig/init/initramfs.c
+++ linux-2.6-ozlabs/init/initramfs.c
@@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
return message;
}
+static int do_retain_initrd = 0;
Don't init that to 0. That's done for us and it's a bit
wasteful in the object file(s), so we try not to do that.
+static int __init retain_initrd_param(char *str)
+{
+ if (*str)
+ return 0;
+ do_retain_initrd = 1;
+ return 1;
+}
+__setup(retain_initrd, retain_initrd_param);
---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] free initrds boot option
On Thu, 07 Dec 2006 11:18:43 +1100
Michael Neuling [EMAIL PROTECTED] wrote:
Add free_initrd= option to control freeing of initrd memory after
extraction. By default, free memory as previously.
Signed-off-by: Michael Neuling [EMAIL PROTECTED]
---
Useful for kexec when you want to reuse the same initrd. Testing on
POWERPC with CPIOs
--- linux-2.6-ozlabs.orig/init/initramfs.c
+++ linux-2.6-ozlabs/init/initramfs.c
@@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
return message;
}
+static int do_free_initrd = 1;
+
+int __init free_initrd_param(char *p)
+{
+ if (p strncmp(p, 0, 1) == 0)
+ do_free_initrd = 0;
+
+ return 0;
+}
+early_param(free_initrd, free_initrd_param);
+
extern char __initramfs_start[], __initramfs_end[];
#ifdef CONFIG_BLK_DEV_INITRD
#include linux/initrd.h
@@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr
static void __init free_initrd(void)
{
-#ifdef CONFIG_KEXEC
unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
unsigned long crashk_end = (unsigned long)__va(crashk_res.end);
+ if (!do_free_initrd)
+ goto skip;
+
+#ifdef CONFIG_KEXEC
/*
* If the initrd region is overlapped with crashkernel reserved region,
* free only memory that is not part of crashkernel region.
@@ -515,7 +529,7 @@ static void __init free_initrd(void)
} else
#endif
free_initrd_mem(initrd_start, initrd_end);
-
+skip:
initrd_start = 0;
initrd_end = 0;
}
I'd have thought that an option `retain_initrd' would make more sense.
Please always update Documentation/kernel-parameters.txt when adding boot
options.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] free initrds boot option
Andrew Morton wrote: I'd have thought that an option `retain_initrd' would make more sense. Please always update Documentation/kernel-parameters.txt when adding boot options. I would have to agree with this; it also seems a bit odd to me to have this at all (kexec provides a new kernel image, surely it also provides a new initrd image???) -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] free initrds boot option
I would have to agree with this; it also seems a bit odd to me to have this at all (kexec provides a new kernel image, surely it also provides a new initrd image???) The first boot will need to hold a copy of the in memory fs for the second boot. This image can be large (much larger than the kernel), hence we can save time when the memory loader is slow. Also, it reduces the memory footprint while extracting the first boot since you don't need another copy of the fs. New patch on it's way. Mikey - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] free initrds boot option
Michael Neuling wrote:
Add free_initrd= option to control freeing of initrd memory after
extraction. By default, free memory as previously.
Signed-off-by: Michael Neuling [EMAIL PROTECTED]
---
Useful for kexec when you want to reuse the same initrd. Testing on
POWERPC with CPIOs
This option (free_initrd) will not work if the user loads the kdump
kernel and does the normal kexec boot later on powerpc. The reason is
initrd will be loaded by yaboot at 36MB and kdump image at 32M (Right
now it is fixed). It could be possible that we will end up overwriting
initrd.
init/initramfs.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
Index: linux-2.6-ozlabs/init/initramfs.c
===
--- linux-2.6-ozlabs.orig/init/initramfs.c
+++ linux-2.6-ozlabs/init/initramfs.c
@@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
return message;
}
+static int do_free_initrd = 1;
+
+int __init free_initrd_param(char *p)
+{
+ if (p strncmp(p, 0, 1) == 0)
+ do_free_initrd = 0;
+
+ return 0;
+}
+early_param(free_initrd, free_initrd_param);
+
extern char __initramfs_start[], __initramfs_end[];
#ifdef CONFIG_BLK_DEV_INITRD
#include linux/initrd.h
@@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr
static void __init free_initrd(void)
{
-#ifdef CONFIG_KEXEC
unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
unsigned long crashk_end = (unsigned long)__va(crashk_res.end);
+ if (!do_free_initrd)
+ goto skip;
+
+#ifdef CONFIG_KEXEC
/*
* If the initrd region is overlapped with crashkernel reserved region,
* free only memory that is not part of crashkernel region.
@@ -515,7 +529,7 @@ static void __init free_initrd(void)
} else
#endif
free_initrd_mem(initrd_start, initrd_end);
-
+skip:
initrd_start = 0;
initrd_end = 0;
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
