n_warn, additional documentation, modify
> !slowpath cases
> [v3]: use proc_dointvec_minmax() in sysctl handler
> [v4]: remove !slowpath cases, and add __read_mostly
> [v5]: change to panic_on_warn, re-alphabetize Documentation/sysctl/kernel.txt
> [v6]: disable on kdump kernel to
't read that part, memory of initrd, cmdline and others
won't be overwritten.
This work is done in x86/boot/compressed/aslr.c::mem_avoid_init().
Thanks
WANG Chao
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
oblem for kdump case:
commit 0d52644
Author: WANG Chao
Date: Fri Mar 28 15:05:00 2014 +0800
x86, kaslr: add alternative way to locate kernel text mapping area
For kexec case, it hangs in purgatory:
[ 556.859384] kexec: Starting new kernel
I'm in purgatory
>
> CCing Kees Coo
: Laurent Dufour
>
> Thanks, applied.
FWIW, this patch works for me. Thanks for the fix.
Thanks
WANG Chao
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
ppc64 big endian platform. If I mask -fexceptions or use a
previous version of kexec (prior to this commit), load is just fine.
Could you please look into this issue? Let me know if you need anything
and I'm happy to test once you have a patch.
Thanks
WANG Chao
(Full output of kexec -d -p):
On 07/10/14 at 11:11am, Anthony Wright wrote:
> Hi Chao,
>
> Thanks for looking at this.
>
> On 10/07/2014 08:47, WANG Chao wrote:
> > Hi, Anthony
> >
> > On 07/08/14 at 11:34am, Anthony Wright wrote:
> >> After successfully modifying kexec-tools
els out the error. The problem is caused by the two
> memory blocks being based at 0x0, causing the blocks to overlap.
The overflow issue should be easy to fix once we figure out why the
crash_reserved_mem[] has a element like that.
Thanks
WANG Chao
>
> I'
On 06/13/14 at 10:10am, Borislav Petkov wrote:
> On Fri, Jun 13, 2014 at 04:00:28PM +0800, WANG Chao wrote:
> > By greping for COMMAND_LINE_SIZE for different arch, I think 8K being
> > the fallback, in general, is good for now and the future:
>
> Why - we could simply use
On 06/13/14 at 09:50am, Borislav Petkov wrote:
> On Mon, Jun 09, 2014 at 11:41:37AM -0400, Vivek Goyal wrote:
> > IIUC, COMMAND_LINE_SIZE gives max limits of running kernel and it does
> > not tell us anything about command line size supported by kernel being
> > loaded.
>
> Whatever you do, you d
wnloaded from kernel.org:
>
>
> http://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools-2.0.7-rc1.tar.xz
Emm.. kexec-tools-2.0.7-rc1.tar.xz? I expect a kexec-tools-2.0.7.tar.xz,
but I couldn't find one.
Thanks
WANG Chao
> http://kernel.org/pub/linux/utils/kerne
eppic -L../eppic/libeppic" eppic_makedumpfile.so
Signed-off-by: WANG Chao
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index d87638b..0cc07ef 100644
--- a/Makefile
+++ b/Makefile
@@ -87,7 +87,7 @@ makedumpfile: $(SRC_BASE) $(OBJ_PAR
On 06/09/14 at 10:11am, Dave Young wrote:
> On 06/06/14 at 02:19pm, Vivek Goyal wrote:
> > On Fri, Jun 06, 2014 at 02:56:05PM +0800, WANG Chao wrote:
> > > On 06/03/14 at 09:06am, Vivek Goyal wrote:
> > > > Previous patch provided the interface def
t;
> + }
> +
> + image->cmdline_buf_len = cmdline_len;
> +
> + /* command line should be a string with last byte null */
> + if (image->cmdline_buf[cmdline_len - 1] != '\0') {
> + ret = -EINVAL;
> +
On 06/05/14 at 11:22am, Vivek Goyal wrote:
> On Thu, Jun 05, 2014 at 11:16:39AM -0400, Vivek Goyal wrote:
> > On Thu, Jun 05, 2014 at 05:56:03PM +0800, WANG Chao wrote:
> >
> > [..]
> > > > diff --git a/kernel/kexec.c b/kernel/kexec.c
> > > > index
int *initrd_fd as the argument? Then
if I don't need initrd, in userspace I can do this:
kexec_file_load(&kernel_fd, NULL, ...)
And even you can remove KEXEC_FILE_UNLOAD flag, because you could tell
that one wants to unload if the following is inv
it.
>
> Takao Indoh (2):
> Enumerate all /sys/devices/system/cpu/cpuN when they are discontiguous
> Fix mistaken check of stat(2) return value
>
> kexec/crashdump-elf.c | 5 -
> kexec/crashdump.c | 2 +-
> 2 files changed, 5 insertions(+), 2 deletions(-)
T
{ "mem-min",1, 0, OPT_MEM_MIN }, \
> { "mem-max",1, 0, OPT_MEM_MAX }, \
> { "reuseinitrd",0, 0, OPT_REUSE_INITRD }, \
> + { "use-kexec2-syscall", 0, 0, OPT_USE_KEXEC2_SYSCALL }, \
>
-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.c | 54 ++---
1 file changed, 23 insertions(+), 31 deletions(-)
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index 15ac4b5..2168854 100644
--- a/kexec/arch/i386/crashdump-x86
On 05/13/14 at 03:09pm, Dave Young wrote:
> Thanks for the cleanup..
>
> On 05/13/14 at 12:51pm, WANG Chao wrote:
> > In kdump path, now we store all the 2nd kernel memory ranges in
> > memmap_p. We could use just cmdline_add_memmap() to add all types of
> > memory r
In kdump path, now we store all the 2nd kernel memory ranges in
memmap_p. We could use just cmdline_add_memmap() to add all types of
memory ranges to 2nd kernel cmdline.
So clean up here, merge cmdline_add_memmap_acpi() into
cmdline_add_memmap().
Signed-off-by: WANG Chao
---
kexec/arch/i386
On 05/08/14 at 10:14am, Vivek Goyal wrote:
> On Thu, May 08, 2014 at 07:26:17PM +0800, WANG Chao wrote:
> > In commit 91f5b9c ("kdump: pass e820 reserved region to 2nd kernel via
> > e820 table or setup_data"), I made a wrong condition check.
> >
> > We shoul
I accidentally add one duplicate line. Now remove it.
Signed-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index cc33347..164ebb2 100644
--- a/kexec/arch/i386/crashdump
via e820 table or setup data").
I've sent a fix:
http://lists.infradead.org/pipermail/kexec/2014-May/011768.html
Please give it try. Thanks in advance.
WANG Chao
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
In commit 91f5b9c ("kdump: pass e820 reserved region to 2nd kernel via
e820 table or setup_data"), I made a wrong condition check.
We should only add cmdline for a memory range if --pass-memmap-cmdline
and the range type isn't RANGE_RESERVED.
Signed-off-by: WANG Chao
---
On 04/28/14 at 03:21pm, WANG Chao wrote:
> e820 reserved region could be useful in 2nd kernel.
>
> For example, PCI mmconf (extended mode) requires reserved region
> otherwise it falls back to legacy mode. The following log is from Cliff
> Wickman :
>
> PCI: MMCONFIG for d
gion because these regions could be too much
and eat up our very limited kernel command line resource in
memmap=exactmap case.
However now we use e820 map and setup_data to pass memory map to 2nd
kernel and the number of reserved regions should not be a problem any
more.
Signed-off-by: WANG Chao
--
gion because these regions could be too much
and eat up our very limited kernel command line resource in
memmap=exactmap case.
However now we use e820 map and setup_data to pass memory map to 2nd
kernel and the number of reserved regions should not be a problem any
more.
Signed-off-by: WANG Chao
--
On 04/23/14 at 09:14am, Simon Horman wrote:
> On Tue, Apr 22, 2014 at 12:37:51PM +0800, WANG Chao wrote:
> > On 04/22/14 at 10:56am, WANG Chao wrote:
> > > Hi, All
> > >
> > > This patchset enables passing memory map via E820 map on x86 platform
> >
On 04/22/14 at 10:56am, WANG Chao wrote:
> Hi, All
>
> This patchset enables passing memory map via E820 map on x86 platform instead
> of memmap=exactmap. It's a better design and will solve the following problem
> so far:
>
> - kernel cmdline is limited resource and l
--pass-memmap-cmdline is used for pass memmap=exactmap cmdline for 2nd
kernel. Later we will use this option to disable passing E820 memmap
method but use the old exactmap method.
Signed-off-by: WANG Chao
Tested-by: Linn Crosetto
Acked-by: Dave Young
---
kexec/arch/i386/include/arch/options.h
emmap=exactmap.
saved_max_pfn users can specify --pass-memmap-cmdline to use the
exactmap approach.
Signed-off-by: WANG Chao
Tested-by: Linn Crosetto
Reviewed-by: Linn Crosetto
Acked-by: Dave Young
---
kexec/arch/i386/crashdump-x86.c | 6 +-
kexec/arch/i386/x86-linux-setup.c
the
unified memory range of both kexec and kdump can use the same E820
filling code.
Signed-off-by: WANG Chao
Acked-by: Dave Young
Tested-by: Linn Crosetto
---
kexec/arch/i386/kexec-x86-common.c | 3 +--
kexec/arch/i386/x86-linux-setup.c | 2 +-
kexec/firmware_memmap.c| 1 -
3 files
Add two new members to kexec_info structure:
struct memory_range *crash_range
int nr_crash_ranges;
crash_range contains the memory ranges used to boot 2nd kernel.
nr_crash_ranges contains the count of the crash memory ranges.
Signed-off-by: WANG Chao
Acked-by: Dave Young
Tested-by: Linn
Signed-off-by: WANG Chao
Acked-by: Dave Young
Tested-by: Linn Crosetto
---
kexec/arch/i386/crashdump-x86.c | 26 +++---
1 file changed, 3 insertions(+), 23 deletions(-)
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index f97d79a..39c35ea
v2->v3:
Linn:
- do not free sd (setup_data) buffer.
- reuse code in setup_e820 and setup_e820_ext.
v1->v2:
Vivek:
- Use function instead of macro for dbgprint_mem_range
- Do not pass reserved memory range for kdump. It could addressed later
separately.
WANG Chao (9):
x86, clea
map_p (nr_memmap) in
add_memmap and delete_memmap, because the counting has already been
taken care of in these two functions.
The original add_memmap() can only add memory range of RANGE_RAM type.
For adding other types of memory range, add another argument for
indicating the type.
Signed-off-by:
for later reference.
Signed-off-by: WANG Chao
Acked-by: Dave Young
Tested-by: Linn Crosetto
---
kexec/arch/i386/crashdump-x86.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index 6dd2e65..f97d79a 100644
CRASH_MAX_MEMMAP_NR is defined (KEXEC_MAX_SEGMENTS + 2), which
is not enough for memmap_p. It must be increased to a much higher value.
I think 1024 is good enough for storing all memory ranges for 2nd
kernel. So this patch increases CRASH_MAX_MEMMAP_NR to 1024.
Signed-off-by: WANG Chao
Acked-by
ve to be aligned.
Signed-off-by: WANG Chao
Acked-by: Dave Young
Tested-by: Linn Crosetto
---
kexec/arch/i386/crashdump-x86.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index dfcce17..6dd2e65 100644
On 04/21/14 at 09:01am, Simon Horman wrote:
> On Thu, Apr 17, 2014 at 01:58:17PM +0800, Dave Young wrote:
> > On 04/17/14 at 01:48pm, WANG Chao wrote:
> > > On 04/17/14 at 01:29pm, Dave Young wrote:
> > > > On 04/14/14 at 10:55pm, WANG Chao wrote:
> > >
On 04/17/14 at 05:45pm, Dave Young wrote:
> >
> > It comes to me that in the future there are two places that can be
> > improved or cleaned up. I summarize them as the followings:
> >
> > - clean up cmdline_add_memmap and cmdline_add_memmap_acpi
> > - Dropping hard limitation memory maps, like C
On 04/17/14 at 03:30pm, Dave Young wrote:
> On 04/17/14 at 03:17pm, WANG Chao wrote:
> > On 04/17/14 at 03:07pm, Dave Young wrote:
> > > On 04/17/14 at 02:57pm, WANG Chao wrote:
> > > > On 04/17/14 at 02:32pm, Dave Young wrote:
> > > > > On 04/17/14 a
On 04/17/14 at 03:07pm, Dave Young wrote:
> On 04/17/14 at 02:57pm, WANG Chao wrote:
> > On 04/17/14 at 02:32pm, Dave Young wrote:
> > > On 04/17/14 at 02:17pm, WANG Chao wrote:
> > > > On 04/17/14 at 01:35pm, Dave Young wrote:
> > > > > On 04/17/14 at
On 04/17/14 at 02:44pm, Dave Young wrote:
> On 04/17/14 at 02:32pm, Dave Young wrote:
> > On 04/17/14 at 02:17pm, WANG Chao wrote:
> > > On 04/17/14 at 01:35pm, Dave Young wrote:
> > > > On 04/17/14 at 01:29pm, Dave Young wrote:
> > > >
On 04/17/14 at 02:32pm, Dave Young wrote:
> On 04/17/14 at 02:17pm, WANG Chao wrote:
> > On 04/17/14 at 01:35pm, Dave Young wrote:
> > > On 04/17/14 at 01:29pm, Dave Young wrote:
> > > > On 04/14/14 at 10:55pm, WANG Chao wrote:
> > > > > command line s
On 04/14/14 at 10:55pm, WANG Chao wrote:
> Hi, All
>
> This patchset enables passing memory map via E820 map on x86 platform instead
> of memmap=exactmap. It's a better design and will solve the following problem
> so far:
>
> - kernel cmdline is limited resource and l
On 04/17/14 at 01:35pm, Dave Young wrote:
> On 04/17/14 at 01:29pm, Dave Young wrote:
> > On 04/14/14 at 10:55pm, WANG Chao wrote:
> > > command line size is restricted by kernel, sometimes memmap=exactmap has
> > > too many memory ranges to pass to cmdline. A
On 04/17/14 at 01:29pm, Dave Young wrote:
> On 04/14/14 at 10:55pm, WANG Chao wrote:
> > command line size is restricted by kernel, sometimes memmap=exactmap has
> > too many memory ranges to pass to cmdline. And also memmap=exactmap and
> > kASLR doesn't work together.
CRASH_MAX_MEMMAP_NR now is defined (KEXEC_MAX_SEGMENTS + 2) which is way
lower than the memmap we can pass to 2nd kernel.
Signed-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kexec/arch/i386/crashdump-x86.h b/kexec/arch
ve to be aligned.
Signed-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index dfcce17..6dd2e65 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec
Signed-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.c | 26 +++---
1 file changed, 3 insertions(+), 23 deletions(-)
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index f97d79a..39c35ea 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b
the
unified memory range of both kexec and kdump can use the same E820
filling code.
Signed-off-by: WANG Chao
---
kexec/arch/i386/kexec-x86-common.c | 3 +--
kexec/arch/i386/x86-linux-setup.c | 2 +-
kexec/firmware_memmap.c| 1 -
3 files changed, 2 insertions(+), 4 deletions(-)
diff
for later reference.
Signed-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index 6dd2e65..f97d79a 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec
--pass-memmap-cmdline is used for pass memmap=exactmap cmdline for 2nd
kernel. Later we will use this option to disable passing E820 memmap
method but use the old exactmap method.
Signed-off-by: WANG Chao
Tested-by: Linn Crosetto
---
kexec/arch/i386/include/arch/options.h | 2 ++
kexec/arch
Add two new members to kexec_info structure:
struct memory_range *crash_range
int nr_crash_ranges;
crash_range contains the memory ranges used to boot 2nd kernel.
nr_crash_ranges contains the count of the crash memory ranges.
Signed-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.c | 6
emmap=exactmap.
saved_max_pfn users can specify --pass-memmap-cmdline to use the
exactmap approach.
Signed-off-by: WANG Chao
Tested-by: Linn Crosetto
Reviewed-by: Linn Crosetto
---
kexec/arch/i386/crashdump-x86.c | 6 +-
kexec/arch/i386/x86-linux-setup.c
e820 and setup_e820_ext.
v1->v2:
Vivek:
- Use function instead of macro for dbgprint_mem_range
- Do not pass reserved memory range for kdump. It could addressed later
separately.
WANG Chao (9):
x86, cleanup: add extra arguments to add_memmap() and delete_memmap()
x86, cleanup: add_
map_p (nr_memmap) in
add_memmap and delete_memmap, because the counting has already been
taken care of in these two functions.
The original add_memmap() can only add memory range of RANGE_RAM type.
For adding other types of memory range, add another argument for
indicating the type.
Signed-off-by:
On 04/14/14 at 11:11am, Simon Horman wrote:
> On Fri, Apr 11, 2014 at 10:23:23AM +0800, WANG Chao wrote:
> > This change will be used later:
> >
> > add_memmap(.., int *nr_memmap, .., int type);
> > delete_memmap(.., int *nr_memmap, ..);
>
> Could you ple
On 04/14/14 at 11:12am, Simon Horman wrote:
> On Fri, Apr 11, 2014 at 10:23:24AM +0800, WANG Chao wrote:
> > Now memmap_p contains all the memory range for 2nd kernel boot.
>
> Could you please include a fuller explanation of what this patch
> achieves and the moti
n the series.
Will do.
>
> On Fri, Apr 11, 2014 at 10:23:25AM +0800, WANG Chao wrote:
> > Signed-off-by: WANG Chao
> > ---
> > kexec/arch/i386/crashdump-x86.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/kexec/arch/i386/
On 04/11/14 at 02:10pm, Dave Young wrote:
> On 04/11/14 at 11:17am, WANG Chao wrote:
> > On 04/11/14 at 10:20am, Dave Young wrote:
> > > On 04/10/14 at 05:13pm, WANG Chao wrote:
> > > > Add two new members to kexec_info structure:
> > > >
> >
On 04/11/14 at 10:22am, Dave Young wrote:
> On 04/10/14 at 05:12pm, WANG Chao wrote:
> > This change will be used later:
> >
> > add_memmap(.., int *nr_memmap, .., int type);
> > delete_memmap(.., int *nr_memmap, ..);
> >
> > Signed-off-by: WANG Chao
>
On 04/11/14 at 11:00am, WANG Chao wrote:
> On 04/11/14 at 10:47am, Dave Young wrote:
> > On 04/10/14 at 07:36pm, H. Peter Anvin wrote:
> > > On 04/10/2014 07:28 PM, Dave Young wrote:
> > > >>
> > > >> +static void add_e820_map_from_mr(st
On 04/11/14 at 10:20am, Dave Young wrote:
> On 04/10/14 at 05:13pm, WANG Chao wrote:
> > Add two new members to kexec_info structure:
> >
> > struct memory_range *crash_range
> > int nr_crash_ranges;
> >
> > crash_range contains the memory ranges used
On 04/10/14 at 05:12pm, WANG Chao wrote:
> Hi, all
>
> (Sorry for this late update. I was occupied with something else)
>
> This patchset enables passing memory map via E820 map on x86 platform instead
> of memmap=exactmap. It's a better design and will solve the fol
On 04/11/14 at 10:24am, Dave Young wrote:
> On 04/10/14 at 05:12pm, WANG Chao wrote:
> > Now memmap_p contains all the memory range for 2nd kernel boot.
>
> Hi, the patch description is not infomative, I still do not get the idea
> why this patch is need, what it is doing..
>
On 04/11/14 at 10:47am, Dave Young wrote:
> On 04/10/14 at 07:36pm, H. Peter Anvin wrote:
> > On 04/10/2014 07:28 PM, Dave Young wrote:
> > >>
> > >> +static void add_e820_map_from_mr(struct x86_linux_param_header
> > >> *real_mode,
> > >> +struct e820entry *e820, struct
add_setup_data() is used to add an instance to the single linked list
of setup_data structure.
Signed-off-by: WANG Chao
---
kexec/arch/i386/x86-linux-setup.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/kexec/arch/i386/x86-linux-setup.c
b
CRASH_MAX_MEMMAP_NR now is defined (KEXEC_MAX_SEGMENTS + 2) which is way
lower than the memmap we can pass to 2nd kernel.
Signed-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kexec/arch/i386/crashdump-x86.h b/kexec/arch
Add two new members to kexec_info structure:
struct memory_range *crash_range
int nr_crash_ranges;
crash_range contains the memory ranges used to boot 2nd kernel.
nr_crash_ranges contains the count of the crash memory ranges.
Signed-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.c | 6
emmap=exactmap.
saved_max_pfn users can specify --pass-memmap-cmdline to use the
exactmap approach.
Signed-off-by: WANG Chao
Tested-by: Linn Crosetto
Reviewed-by: Linn Crosetto
Signed-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.c | 6 +-
kexec/arch/i386/x86-linux-setup.c
Signed-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index 43eb8f7..4072c10 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386
--pass-memmap-cmdline is used for pass memmap=exactmap cmdline for 2nd
kernel. Later we will use this option to disable passing E820 memmap
method but use the old exactmap method.
Signed-off-by: WANG Chao
Tested-by: Linn Crosetto
---
kexec/arch/i386/include/arch/options.h | 2 ++
kexec/arch
Signed-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index 91872ab..72bce0b 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386
This change will be used later:
add_memmap(.., int *nr_memmap, .., int type);
delete_memmap(.., int *nr_memmap, ..);
Signed-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/kexec/arch/i386
Signed-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.c | 26 +++---
1 file changed, 3 insertions(+), 23 deletions(-)
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index 4072c10..2437c30 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b
Now memmap_p contains all the memory range for 2nd kernel boot.
Signed-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index e695eaf..43eb8f7 100644
se function instead of macro for dbgprint_mem_range
- Do not pass reserved memory range for kdump. It could addressed later
separately.
WANG Chao (10):
x86, cleanup: fix indent
x86, cleanup: add extra arguments to add_memmap() and delete_memmap()
x86, cleanup: add other types of memory range for
se function instead of macro for dbgprint_mem_range
- Do not pass reserved memory range for kdump. It could addressed later
separately.
WANG Chao (10):
x86, cleanup: fix indent
x86, cleanup: add extra arguments to add_memmap() and delete_memmap()
x86, cleanup: add other types of memory range for
On 04/11/14 at 10:06am, Dave Young wrote:
> On 04/10/14 at 05:12pm, WANG Chao wrote:
> > Hi, all
> >
> > (Sorry for this late update. I was occupied with something else)
> >
> > This patchset enables passing memory map via E820 map on x86 platform
> >
On 04/11/14 at 10:00am, Dave Young wrote:
> > Is the definition for dbgprint_mem_range() missing? It was added in patch
> > v4 1/4
> > but I do not see it in this set.
>
> I think that one has been merged by Simon..
Yes, Simon has picked up this one.
add_setup_data() is used to add an instance to the single linked list
of setup_data structure.
Signed-off-by: WANG Chao
---
kexec/arch/i386/x86-linux-setup.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/kexec/arch/i386/x86-linux-setup.c
b
add_setup_data() is used to add an instance to the single linked list
of setup_data structure.
Signed-off-by: WANG Chao
---
kexec/arch/i386/x86-linux-setup.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/kexec/arch/i386/x86-linux-setup.c
b
--pass-memmap-cmdline is used for pass memmap=exactmap cmdline for 2nd
kernel. Later we will use this option to disable passing E820 memmap
method but use the old exactmap method.
Signed-off-by: WANG Chao
Tested-by: Linn Crosetto
---
kexec/arch/i386/include/arch/options.h | 2 ++
kexec/arch
--pass-memmap-cmdline is used for pass memmap=exactmap cmdline for 2nd
kernel. Later we will use this option to disable passing E820 memmap
method but use the old exactmap method.
Signed-off-by: WANG Chao
Tested-by: Linn Crosetto
---
kexec/arch/i386/include/arch/options.h | 2 ++
kexec/arch
Add two new members to kexec_info structure:
struct memory_range *crash_range
int nr_crash_ranges;
crash_range contains the memory ranges used to boot 2nd kernel.
nr_crash_ranges contains the count of the crash memory ranges.
Signed-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.c | 6
emmap=exactmap.
saved_max_pfn users can specify --pass-memmap-cmdline to use the
exactmap approach.
Signed-off-by: WANG Chao
Tested-by: Linn Crosetto
Reviewed-by: Linn Crosetto
Signed-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.c | 6 +-
kexec/arch/i386/x86-linux-setup.c
Add two new members to kexec_info structure:
struct memory_range *crash_range
int nr_crash_ranges;
crash_range contains the memory ranges used to boot 2nd kernel.
nr_crash_ranges contains the count of the crash memory ranges.
Signed-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.c | 6
This change will be used later:
add_memmap(.., int *nr_memmap, .., int type);
delete_memmap(.., int *nr_memmap, ..);
Signed-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/kexec/arch/i386
Signed-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index 43eb8f7..4072c10 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386
ge for kdump. It could addressed later
separately.
WANG Chao (10):
x86, cleanup: fix indent
x86, cleanup: add extra arguments to add_memmap() and delete_memmap()
x86, cleanup: add other types of memory range for 2nd kernel boot to
memmap_p
x86, cleanup: add_memmap() only do al
Signed-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.c | 26 +++---
1 file changed, 3 insertions(+), 23 deletions(-)
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index 4072c10..2437c30 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b
Now memmap_p contains all the memory range for 2nd kernel boot.
Signed-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index e695eaf..43eb8f7 100644
CRASH_MAX_MEMMAP_NR now is defined (KEXEC_MAX_SEGMENTS + 2) which is way
lower than the memmap we can pass to 2nd kernel.
Signed-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kexec/arch/i386/crashdump-x86.h b/kexec/arch
Signed-off-by: WANG Chao
---
kexec/arch/i386/crashdump-x86.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index 91872ab..72bce0b 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386
On 04/01/14 at 05:36pm, Dave Young wrote:
> On 04/01/14 at 04:54pm, WANG Chao wrote:
> > On 04/01/14 at 04:41pm, Dave Young wrote:
> > > On 04/01/14 at 03:04pm, WANG Chao wrote:
> > > > On 03/28/14 at 02:43pm, Dave Young wrote:
> > > > > On 03/28/14 a
On 04/01/14 at 04:41pm, Dave Young wrote:
> On 04/01/14 at 03:04pm, WANG Chao wrote:
> > On 03/28/14 at 02:43pm, Dave Young wrote:
> > > On 03/28/14 at 02:13pm, WANG Chao wrote:
> > > > On 03/28/14 at 11:24am, Dave Young wrote:
> > > > > >
> >
On 03/28/14 at 02:43pm, Dave Young wrote:
> On 03/28/14 at 02:13pm, WANG Chao wrote:
> > On 03/28/14 at 11:24am, Dave Young wrote:
> > > >
> > > > +static void exclude_ram(struct memory_range *mr, int *nr_mr)
> > > > +{
> > > > +
from
/proc/kallsyms, and search for kcore's PT_LOAD which contains _stext,
and we can say that this area represents the kernel mapping area.
Let's first use this way to find out kernel text mapping. If failed for
whatever reason, fall back to use the old way.
Suggested-by: Vivek Goyal
Sign
1 - 100 of 187 matches
Mail list logo
