* [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG). @ 2012-10-31 1:26 Zhang, Jun 2012-10-31 2:46 ` H. Peter Anvin 0 siblings, 1 reply; 15+ messages in thread From: Zhang, Jun @ 2012-10-31 1:26 UTC (permalink / raw) To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86@kernel.org, Andrew Morton, Fleming, Matt, Paul Gortmaker, linux-kernel@vger.kernel.org Cc: Zhang, Jun >From aebc336baa7ec2d4ccb6f21166770c7d2ee26cba Mon Sep 17 00:00:00 2001 From: jzha144 <jun.zhang@intel.com> Date: Wed, 31 Oct 2012 08:51:18 +0800 Subject: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG). Signed-off-by: jzha144 <jun.zhang@intel.com> --- arch/x86/kernel/e820.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index df06ade..8760427 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -851,6 +851,15 @@ static int __init parse_memmap_opt(char *p) * reset. */ saved_max_pfn = e820_end_of_ram_pfn(); + + /* + * To CRASH DUMP, only remove E820_RAM. + * some other memory typecome from BIOS or firmware, + * it must be same with system kernel. + */ + e820_remove_range(0, ULLONG_MAX, E820_RAM, 1); + userdef = 1; + return 0; #endif e820.nr_map = 0; userdef = 1; -- 1.7.6 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG). 2012-10-31 1:26 [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG) Zhang, Jun @ 2012-10-31 2:46 ` H. Peter Anvin 2012-10-31 3:39 ` Zhang, Jun 0 siblings, 1 reply; 15+ messages in thread From: H. Peter Anvin @ 2012-10-31 2:46 UTC (permalink / raw) To: Zhang, Jun Cc: Thomas Gleixner, Ingo Molnar, x86@kernel.org, Andrew Morton, Fleming, Matt, Paul Gortmaker, linux-kernel@vger.kernel.org On 10/30/2012 06:26 PM, Zhang, Jun wrote: > From aebc336baa7ec2d4ccb6f21166770c7d2ee26cba Mon Sep 17 00:00:00 2001 > From: jzha144 <jun.zhang@intel.com> > Date: Wed, 31 Oct 2012 08:51:18 +0800 > Subject: [PATCH] To crash dump, we need keep other memory type except > E820_RAM, because other type come from BIOS or firmware is > used by other code(for example: PCI_MMCONFIG). I'm sorry, I can't quite parse the description or the comment... could you clarify it a bit? I think I know what you mean, but there is clearly risk for misunderstandings. -hpa ^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG). 2012-10-31 2:46 ` H. Peter Anvin @ 2012-10-31 3:39 ` Zhang, Jun 2012-10-31 4:38 ` H. Peter Anvin 0 siblings, 1 reply; 15+ messages in thread From: Zhang, Jun @ 2012-10-31 3:39 UTC (permalink / raw) To: H. Peter Anvin Cc: Thomas Gleixner, Ingo Molnar, x86@kernel.org, Andrew Morton, Fleming, Matt, Paul Gortmaker, linux-kernel@vger.kernel.org Hello, Anvin Thanks! Hello, all Next is my the latest version, please review it. Thanks! >From 141546c77ff7be523a9e72f5259df4a6827f2c1a Mon Sep 17 00:00:00 2001 From: jzha144 <jun.zhang@intel.com> Date: Wed, 31 Oct 2012 08:51:18 +0800 Subject: [PATCH] If we are doing a crash dump, we still need non-E820_RAM memory type address information, which come from BIOS or firmware. for example: PCI_MMCONFIG check this address. Signed-off-by: jzha144 <jun.zhang@intel.com> --- arch/x86/kernel/e820.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index df06ade..f8672d0 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -851,6 +851,15 @@ static int __init parse_memmap_opt(char *p) * reset. */ saved_max_pfn = e820_end_of_ram_pfn(); + + /* + * If we are doing a crash dump, we still need non-E820_RAM + * memory type address information. so we only remove + * E820_RAM type. + */ + e820_remove_range(0, ULLONG_MAX, E820_RAM, 1); + userdef = 1; + return 0; #endif e820.nr_map = 0; userdef = 1; -- 1.7.6 Best Regards! Jun Zhang Inet: 8821-4273 Dir.Tel: 86-21-6116-4273 Email: jun.zhang@intel.com -----Original Message----- From: H. Peter Anvin [mailto:hpa@zytor.com] Sent: Wednesday, October 31, 2012 10:47 AM To: Zhang, Jun Cc: Thomas Gleixner; Ingo Molnar; x86@kernel.org; Andrew Morton; Fleming, Matt; Paul Gortmaker; linux-kernel@vger.kernel.org Subject: Re: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG). On 10/30/2012 06:26 PM, Zhang, Jun wrote: > From aebc336baa7ec2d4ccb6f21166770c7d2ee26cba Mon Sep 17 00:00:00 2001 > From: jzha144 <jun.zhang@intel.com> > Date: Wed, 31 Oct 2012 08:51:18 +0800 > Subject: [PATCH] To crash dump, we need keep other memory type except > E820_RAM, because other type come from BIOS or firmware is used by > other code(for example: PCI_MMCONFIG). I'm sorry, I can't quite parse the description or the comment... could you clarify it a bit? I think I know what you mean, but there is clearly risk for misunderstandings. -hpa ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG). 2012-10-31 3:39 ` Zhang, Jun @ 2012-10-31 4:38 ` H. Peter Anvin 2012-10-31 5:22 ` Zhang, Jun 0 siblings, 1 reply; 15+ messages in thread From: H. Peter Anvin @ 2012-10-31 4:38 UTC (permalink / raw) To: Zhang, Jun Cc: Thomas Gleixner, Ingo Molnar, x86@kernel.org, Andrew Morton, Fleming, Matt, Paul Gortmaker, linux-kernel@vger.kernel.org On 10/30/2012 08:39 PM, Zhang, Jun wrote: > Hello, Anvin > Thanks! > > Hello, all > Next is my the latest version, please review it. > Thanks! You're still starting in the wrong end which is confusing for the reader. What you probably want to say is something more like: "We are doing a crash dump, so remove all RAM ranges as they are the ones that need to be dumped. We still need all non-RAM information in order to do I/O." At that point it should be pretty obvious that the patch is wrong. What if we are *not* doing a crash dump? Just because crash dump is compiled in doesn't mean that that is what we are doing right now. -hpa > From 141546c77ff7be523a9e72f5259df4a6827f2c1a Mon Sep 17 00:00:00 2001 > From: jzha144 <jun.zhang@intel.com> > Date: Wed, 31 Oct 2012 08:51:18 +0800 > Subject: [PATCH] If we are doing a crash dump, we still need non-E820_RAM > memory type address information, which come from BIOS or > firmware. for example: PCI_MMCONFIG check this address. > > Signed-off-by: jzha144 <jun.zhang@intel.com> > --- > arch/x86/kernel/e820.c | 9 +++++++++ > 1 files changed, 9 insertions(+), 0 deletions(-) > > diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c > index df06ade..f8672d0 100644 > --- a/arch/x86/kernel/e820.c > +++ b/arch/x86/kernel/e820.c > @@ -851,6 +851,15 @@ static int __init parse_memmap_opt(char *p) > * reset. > */ > saved_max_pfn = e820_end_of_ram_pfn(); > + > + /* > + * If we are doing a crash dump, we still need non-E820_RAM > + * memory type address information. so we only remove > + * E820_RAM type. > + */ > + e820_remove_range(0, ULLONG_MAX, E820_RAM, 1); > + userdef = 1; > + return 0; > #endif > e820.nr_map = 0; > userdef = 1; > -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG). 2012-10-31 4:38 ` H. Peter Anvin @ 2012-10-31 5:22 ` Zhang, Jun 2012-10-31 5:38 ` H. Peter Anvin 0 siblings, 1 reply; 15+ messages in thread From: Zhang, Jun @ 2012-10-31 5:22 UTC (permalink / raw) To: H. Peter Anvin Cc: Thomas Gleixner, Ingo Molnar, x86@kernel.org, Andrew Morton, Fleming, Matt, Paul Gortmaker, linux-kernel@vger.kernel.org [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3641 bytes --] Hello, Anvin You are right. Thanks! Hello, All Please review it again. Thanks! >From bf7506ac7e9ce0df0b915164dbb7a6d858ef2e40 Mon Sep 17 00:00:00 2001 From: jzha144 <jun.zhang@intel.com> Date: Wed, 31 Oct 2012 08:51:18 +0800 Subject: [PATCH] When we are doing a crash dump, we still need non-E820_RAM memory type address information in order to do I/O. so only remove all RAM ranges which need to be dumped. Signed-off-by: jzha144 <jun.zhang@intel.com> --- arch/x86/kernel/e820.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index df06ade..77be839 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -851,6 +851,15 @@ static int __init parse_memmap_opt(char *p) * reset. */ saved_max_pfn = e820_end_of_ram_pfn(); + + /* + * We are doing a crash dump, so remove all RAM ranges + * as they are the ones that need to be dumped. + * We still need all non-RAM information in order to do I/O. + */ + e820_remove_range(0, ULLONG_MAX, E820_RAM, 1); + userdef = 1; + return 0; #endif e820.nr_map = 0; userdef = 1; -- 1.7.6 Best Regards! Zhang, jun -----Original Message----- From: H. Peter Anvin [mailto:hpa@zytor.com] Sent: Wednesday, October 31, 2012 12:38 PM To: Zhang, Jun Cc: Thomas Gleixner; Ingo Molnar; x86@kernel.org; Andrew Morton; Fleming, Matt; Paul Gortmaker; linux-kernel@vger.kernel.org Subject: Re: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG). On 10/30/2012 08:39 PM, Zhang, Jun wrote: > Hello, Anvin > Thanks! > > Hello, all > Next is my the latest version, please review it. > Thanks! You're still starting in the wrong end which is confusing for the reader. What you probably want to say is something more like: "We are doing a crash dump, so remove all RAM ranges as they are the ones that need to be dumped. We still need all non-RAM information in order to do I/O." At that point it should be pretty obvious that the patch is wrong. What if we are *not* doing a crash dump? Just because crash dump is compiled in doesn't mean that that is what we are doing right now. -hpa > From 141546c77ff7be523a9e72f5259df4a6827f2c1a Mon Sep 17 00:00:00 > 2001 > From: jzha144 <jun.zhang@intel.com> > Date: Wed, 31 Oct 2012 08:51:18 +0800 > Subject: [PATCH] If we are doing a crash dump, we still need non-E820_RAM > memory type address information, which come from BIOS or > firmware. for example: PCI_MMCONFIG check this address. > > Signed-off-by: jzha144 <jun.zhang@intel.com> > --- > arch/x86/kernel/e820.c | 9 +++++++++ > 1 files changed, 9 insertions(+), 0 deletions(-) > > diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index > df06ade..f8672d0 100644 > --- a/arch/x86/kernel/e820.c > +++ b/arch/x86/kernel/e820.c > @@ -851,6 +851,15 @@ static int __init parse_memmap_opt(char *p) > * reset. > */ > saved_max_pfn = e820_end_of_ram_pfn(); > + > + /* > + * If we are doing a crash dump, we still need non-E820_RAM > + * memory type address information. so we only remove > + * E820_RAM type. > + */ > + e820_remove_range(0, ULLONG_MAX, E820_RAM, 1); > + userdef = 1; > + return 0; > #endif > e820.nr_map = 0; > userdef = 1; > -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG). 2012-10-31 5:22 ` Zhang, Jun @ 2012-10-31 5:38 ` H. Peter Anvin 2012-11-01 2:15 ` Zhang, Jun 0 siblings, 1 reply; 15+ messages in thread From: H. Peter Anvin @ 2012-10-31 5:38 UTC (permalink / raw) To: Zhang, Jun Cc: Thomas Gleixner, Ingo Molnar, x86@kernel.org, Andrew Morton, Fleming, Matt, Paul Gortmaker, linux-kernel@vger.kernel.org On 10/30/2012 10:22 PM, Zhang, Jun wrote: > Hello, Anvin > You are right. Thanks! > > Hello, All > Please review it again. Thanks! > > From bf7506ac7e9ce0df0b915164dbb7a6d858ef2e40 Mon Sep 17 00:00:00 2001 > From: jzha144 <jun.zhang@intel.com> > Date: Wed, 31 Oct 2012 08:51:18 +0800 > Subject: [PATCH] When we are doing a crash dump, we still need non-E820_RAM > memory type address information in order to do I/O. so only > remove all RAM ranges which need to be dumped. > > Signed-off-by: jzha144 <jun.zhang@intel.com> > --- > arch/x86/kernel/e820.c | 9 +++++++++ > 1 files changed, 9 insertions(+), 0 deletions(-) > > diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c > index df06ade..77be839 100644 > --- a/arch/x86/kernel/e820.c > +++ b/arch/x86/kernel/e820.c > @@ -851,6 +851,15 @@ static int __init parse_memmap_opt(char *p) > * reset. > */ > saved_max_pfn = e820_end_of_ram_pfn(); > + > + /* > + * We are doing a crash dump, so remove all RAM ranges > + * as they are the ones that need to be dumped. > + * We still need all non-RAM information in order to do I/O. > + */ > + e820_remove_range(0, ULLONG_MAX, E820_RAM, 1); > + userdef = 1; > + return 0; > #endif > e820.nr_map = 0; > userdef = 1; > The code is still wrong... -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG). 2012-10-31 5:38 ` H. Peter Anvin @ 2012-11-01 2:15 ` Zhang, Jun 2012-11-01 4:20 ` H. Peter Anvin 0 siblings, 1 reply; 15+ messages in thread From: Zhang, Jun @ 2012-11-01 2:15 UTC (permalink / raw) To: H. Peter Anvin Cc: Thomas Gleixner, Ingo Molnar, x86@kernel.org, Andrew Morton, Fleming, Matt, Paul Gortmaker, linux-kernel@vger.kernel.org [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2622 bytes --] Hello, Anvin I want to explain why I modify in this place. In kexec, it pass three parameters, memmap=exactmap memmap=544K@64K memmap=64964K@32768K I think my patch modify the least code. Actually, there are some choise to fix it. 1) my patch. 2) modify kexec, only pass two parameters -- memmap=544K@64K memmap=64964K@32768K, in kernel setup_memory_map, we can remove RAM range. 3) add extra optional, like memmap=REMOVERAM Which one do you like? Maybe you have better solution, please share it. Thanks! Best Regards! Jun Zhang Inet: 8821-4273 Dir.Tel: 86-21-6116-4273 Email: jun.zhang@intel.com -----Original Message----- From: H. Peter Anvin [mailto:hpa@zytor.com] Sent: Wednesday, October 31, 2012 1:39 PM To: Zhang, Jun Cc: Thomas Gleixner; Ingo Molnar; x86@kernel.org; Andrew Morton; Fleming, Matt; Paul Gortmaker; linux-kernel@vger.kernel.org Subject: Re: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG). On 10/30/2012 10:22 PM, Zhang, Jun wrote: > Hello, Anvin > You are right. Thanks! > > Hello, All > Please review it again. Thanks! > > From bf7506ac7e9ce0df0b915164dbb7a6d858ef2e40 Mon Sep 17 00:00:00 > 2001 > From: jzha144 <jun.zhang@intel.com> > Date: Wed, 31 Oct 2012 08:51:18 +0800 > Subject: [PATCH] When we are doing a crash dump, we still need non-E820_RAM > memory type address information in order to do I/O. so only > remove all RAM ranges which need to be dumped. > > Signed-off-by: jzha144 <jun.zhang@intel.com> > --- > arch/x86/kernel/e820.c | 9 +++++++++ > 1 files changed, 9 insertions(+), 0 deletions(-) > > diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index > df06ade..77be839 100644 > --- a/arch/x86/kernel/e820.c > +++ b/arch/x86/kernel/e820.c > @@ -851,6 +851,15 @@ static int __init parse_memmap_opt(char *p) > * reset. > */ > saved_max_pfn = e820_end_of_ram_pfn(); > + > + /* > + * We are doing a crash dump, so remove all RAM ranges > + * as they are the ones that need to be dumped. > + * We still need all non-RAM information in order to do I/O. > + */ > + e820_remove_range(0, ULLONG_MAX, E820_RAM, 1); > + userdef = 1; > + return 0; > #endif > e820.nr_map = 0; > userdef = 1; > The code is still wrong... -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG). 2012-11-01 2:15 ` Zhang, Jun @ 2012-11-01 4:20 ` H. Peter Anvin 2012-11-01 8:49 ` Zhang, Jun 0 siblings, 1 reply; 15+ messages in thread From: H. Peter Anvin @ 2012-11-01 4:20 UTC (permalink / raw) To: Zhang, Jun Cc: Thomas Gleixner, Ingo Molnar, x86@kernel.org, Andrew Morton, Fleming, Matt, Paul Gortmaker, linux-kernel@vger.kernel.org 2) would make most sense to me, but I'd be okay with 3) as well. "Zhang, Jun" <jun.zhang@intel.com> wrote: >Hello, Anvin > >I want to explain why I modify in this place. In kexec, it pass three >parameters, memmap=exactmap memmap=544K@64K memmap=64964K@32768K >I think my patch modify the least code. >Actually, there are some choise to fix it. >1) my patch. >2) modify kexec, only pass two parameters -- memmap=544K@64K >memmap=64964K@32768K, in kernel setup_memory_map, we can remove RAM >range. >3) add extra optional, like memmap=REMOVERAM > >Which one do you like? Maybe you have better solution, please share it. >Thanks! > >Best Regards! > >Jun Zhang >Inet: 8821-4273 >Dir.Tel: 86-21-6116-4273 >Email: jun.zhang@intel.com > >-----Original Message----- >From: H. Peter Anvin [mailto:hpa@zytor.com] >Sent: Wednesday, October 31, 2012 1:39 PM >To: Zhang, Jun >Cc: Thomas Gleixner; Ingo Molnar; x86@kernel.org; Andrew Morton; >Fleming, Matt; Paul Gortmaker; linux-kernel@vger.kernel.org >Subject: Re: [PATCH] To crash dump, we need keep other memory type >except E820_RAM, because other type come from BIOS or firmware is used >by other code(for example: PCI_MMCONFIG). > >On 10/30/2012 10:22 PM, Zhang, Jun wrote: >> Hello, Anvin >> You are right. Thanks! >> >> Hello, All >> Please review it again. Thanks! >> >> From bf7506ac7e9ce0df0b915164dbb7a6d858ef2e40 Mon Sep 17 00:00:00 >> 2001 >> From: jzha144 <jun.zhang@intel.com> >> Date: Wed, 31 Oct 2012 08:51:18 +0800 >> Subject: [PATCH] When we are doing a crash dump, we still need >non-E820_RAM >> memory type address information in order to do I/O. so only >> remove all RAM ranges which need to be dumped. >> >> Signed-off-by: jzha144 <jun.zhang@intel.com> >> --- >> arch/x86/kernel/e820.c | 9 +++++++++ >> 1 files changed, 9 insertions(+), 0 deletions(-) >> >> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index >> df06ade..77be839 100644 >> --- a/arch/x86/kernel/e820.c >> +++ b/arch/x86/kernel/e820.c >> @@ -851,6 +851,15 @@ static int __init parse_memmap_opt(char *p) >> * reset. >> */ >> saved_max_pfn = e820_end_of_ram_pfn(); >> + >> + /* >> + * We are doing a crash dump, so remove all RAM ranges >> + * as they are the ones that need to be dumped. >> + * We still need all non-RAM information in order to do I/O. >> + */ >> + e820_remove_range(0, ULLONG_MAX, E820_RAM, 1); >> + userdef = 1; >> + return 0; >> #endif >> e820.nr_map = 0; >> userdef = 1; >> > >The code is still wrong... > > -hpa > > >-- >H. Peter Anvin, Intel Open Source Technology Center I work for Intel. >I don't speak on their behalf. -- Sent from my mobile phone. Please excuse brevity and lack of formatting. ^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG). 2012-11-01 4:20 ` H. Peter Anvin @ 2012-11-01 8:49 ` Zhang, Jun 2012-11-02 15:08 ` Paul Gortmaker 2012-11-02 16:37 ` H. Peter Anvin 0 siblings, 2 replies; 15+ messages in thread From: Zhang, Jun @ 2012-11-01 8:49 UTC (permalink / raw) To: H. Peter Anvin Cc: Thomas Gleixner, Ingo Molnar, x86@kernel.org, Andrew Morton, Fleming, Matt, Paul Gortmaker, linux-kernel@vger.kernel.org [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 5670 bytes --] Hello, Anvin Thank for your advice. Hello, All the next patch is made by 2), please review it. Thanks! Subject: [PATCH] When we are doing a crash dump, we still need non-E820_RAM memory information in order to do I/O. So only remove all RAM ranges which need to be dumped. Signed-off-by: jzha144 <jun.zhang@intel.com> --- arch/x86/kernel/e820.c | 8 -------- arch/x86/kernel/setup.c | 22 ++++++++++++++++++++++ 2 files changed, 22 insertions(+), 8 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index df06ade..0bc1687 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -844,14 +844,6 @@ static int __init parse_memmap_opt(char *p) return -EINVAL; if (!strncmp(p, "exactmap", 8)) { -#ifdef CONFIG_CRASH_DUMP - /* - * If we are doing a crash dump, we still need to know - * the real mem size before original memory map is - * reset. - */ - saved_max_pfn = e820_end_of_ram_pfn(); -#endif e820.nr_map = 0; userdef = 1; return 0; diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index ca45696..5eb178b 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -480,6 +480,25 @@ static void __init e820_reserve_setup_data(void) e820_print_map("reserve setup_data"); } +#ifdef CONFIG_CRASH_DUMP +static void __init e820_crashdump_remove_ram(void) +{ + /* + * We are doing a crash dump, so remove all RAM ranges + * as they are the ones that need to be dumped. + * We still need all non-RAM information in order to do I/O. + */ + /* NOTE: if you use old kexec, please remove memmap=exactmap + * which remove all ranges, not only RAM ranges. + */ + saved_max_pfn = e820_end_of_ram_pfn(); + e820_remove_range(0, ULLONG_MAX, E820_RAM, 1); + sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); + printk(KERN_INFO "crash dump non-RAM map:\n"); + e820_print_map("crash_dump"); +} +#endif + static void __init memblock_x86_reserve_range_setup_data(void) { struct setup_data *data; @@ -751,6 +770,9 @@ void __init setup_arch(char **cmdline_p) parse_setup_data(); /* update the e820_saved too */ e820_reserve_setup_data(); +#ifdef CONFIG_CRASH_DUMP + e820_crashdump_remove_ram(); +#endif copy_edd(); -- 1.7.6 Best Regards! Jun Zhang Inet: 8821-4273 Dir.Tel: 86-21-6116-4273 Email: jun.zhang@intel.com -----Original Message----- From: H. Peter Anvin [mailto:hpa@zytor.com] Sent: Thursday, November 01, 2012 12:20 PM To: Zhang, Jun Cc: Thomas Gleixner; Ingo Molnar; x86@kernel.org; Andrew Morton; Fleming, Matt; Paul Gortmaker; linux-kernel@vger.kernel.org Subject: RE: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG). 2) would make most sense to me, but I'd be okay with 3) as well. "Zhang, Jun" <jun.zhang@intel.com> wrote: >Hello, Anvin > >I want to explain why I modify in this place. In kexec, it pass three >parameters, memmap=exactmap memmap=544K@64K memmap=64964K@32768K I >think my patch modify the least code. >Actually, there are some choise to fix it. >1) my patch. >2) modify kexec, only pass two parameters -- memmap=544K@64K >memmap=64964K@32768K, in kernel setup_memory_map, we can remove RAM >range. >3) add extra optional, like memmap=REMOVERAM > >Which one do you like? Maybe you have better solution, please share it. >Thanks! > >Best Regards! > >Jun Zhang >Inet: 8821-4273 >Dir.Tel: 86-21-6116-4273 >Email: jun.zhang@intel.com > >-----Original Message----- >From: H. Peter Anvin [mailto:hpa@zytor.com] >Sent: Wednesday, October 31, 2012 1:39 PM >To: Zhang, Jun >Cc: Thomas Gleixner; Ingo Molnar; x86@kernel.org; Andrew Morton; >Fleming, Matt; Paul Gortmaker; linux-kernel@vger.kernel.org >Subject: Re: [PATCH] To crash dump, we need keep other memory type >except E820_RAM, because other type come from BIOS or firmware is used >by other code(for example: PCI_MMCONFIG). > >On 10/30/2012 10:22 PM, Zhang, Jun wrote: >> Hello, Anvin >> You are right. Thanks! >> >> Hello, All >> Please review it again. Thanks! >> >> From bf7506ac7e9ce0df0b915164dbb7a6d858ef2e40 Mon Sep 17 00:00:00 >> 2001 >> From: jzha144 <jun.zhang@intel.com> >> Date: Wed, 31 Oct 2012 08:51:18 +0800 >> Subject: [PATCH] When we are doing a crash dump, we still need >non-E820_RAM >> memory type address information in order to do I/O. so only >> remove all RAM ranges which need to be dumped. >> >> Signed-off-by: jzha144 <jun.zhang@intel.com> >> --- >> arch/x86/kernel/e820.c | 9 +++++++++ >> 1 files changed, 9 insertions(+), 0 deletions(-) >> >> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index >> df06ade..77be839 100644 >> --- a/arch/x86/kernel/e820.c >> +++ b/arch/x86/kernel/e820.c >> @@ -851,6 +851,15 @@ static int __init parse_memmap_opt(char *p) >> * reset. >> */ >> saved_max_pfn = e820_end_of_ram_pfn(); >> + >> + /* >> + * We are doing a crash dump, so remove all RAM ranges >> + * as they are the ones that need to be dumped. >> + * We still need all non-RAM information in order to do I/O. >> + */ >> + e820_remove_range(0, ULLONG_MAX, E820_RAM, 1); >> + userdef = 1; >> + return 0; >> #endif >> e820.nr_map = 0; >> userdef = 1; >> > >The code is still wrong... > > -hpa > > >-- >H. Peter Anvin, Intel Open Source Technology Center I work for Intel. >I don't speak on their behalf. -- Sent from my mobile phone. Please excuse brevity and lack of formatting. ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG). 2012-11-01 8:49 ` Zhang, Jun @ 2012-11-02 15:08 ` Paul Gortmaker 2012-11-02 16:37 ` H. Peter Anvin 1 sibling, 0 replies; 15+ messages in thread From: Paul Gortmaker @ 2012-11-02 15:08 UTC (permalink / raw) To: Zhang, Jun Cc: H. Peter Anvin, Thomas Gleixner, Ingo Molnar, x86@kernel.org, Andrew Morton, Fleming, Matt, linux-kernel@vger.kernel.org [RE: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG).] On 01/11/2012 (Thu 08:49) Zhang, Jun wrote: > Hello, Anvin > > Thank for your advice. > > Hello, All > > the next patch is made by 2), please review it. Thanks! > > Subject: [PATCH] When we are doing a crash dump, we still need non-E820_RAM > memory information in order to do I/O. So only remove all > RAM ranges which need to be dumped. It is typical to do a "short log" in the subject, and then a "long log" in what would be the following paragraph, i.e. --------- Subject: crash dump: don't delete non-E820_RAM during init Currently we delete the non-E820_RAM, which causes <describe the end user symptoms here -- i.e. how things visibly break> This happens because <describe the underlying technical reason that causes the problem> We can fix this by doing <describe the non-obvious aspects of your change and why it is the right way to fix the problem> --------- This "rule of three" is a good way to write commit logs. Just remember (1)symptoms, (2)underlying problem, (3)how best to fix it. Also, ... > > Signed-off-by: jzha144 <jun.zhang@intel.com> > --- > arch/x86/kernel/e820.c | 8 -------- > arch/x86/kernel/setup.c | 22 ++++++++++++++++++++++ > 2 files changed, 22 insertions(+), 8 deletions(-) > > diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c > index df06ade..0bc1687 100644 > --- a/arch/x86/kernel/e820.c > +++ b/arch/x86/kernel/e820.c > @@ -844,14 +844,6 @@ static int __init parse_memmap_opt(char *p) > return -EINVAL; > > if (!strncmp(p, "exactmap", 8)) { > -#ifdef CONFIG_CRASH_DUMP > - /* > - * If we are doing a crash dump, we still need to know > - * the real mem size before original memory map is > - * reset. > - */ > - saved_max_pfn = e820_end_of_ram_pfn(); > -#endif > e820.nr_map = 0; > userdef = 1; > return 0; > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > index ca45696..5eb178b 100644 > --- a/arch/x86/kernel/setup.c > +++ b/arch/x86/kernel/setup.c > @@ -480,6 +480,25 @@ static void __init e820_reserve_setup_data(void) > e820_print_map("reserve setup_data"); > } > > +#ifdef CONFIG_CRASH_DUMP > +static void __init e820_crashdump_remove_ram(void) > +{ ... if you move this ifdef/endif within the { } of the function, then we'll have one less ugly ifdef set below at the call site. I'll leave the real technical review for Peter, who understands this area better than I ever will. Thanks, Paul. -- > + /* > + * We are doing a crash dump, so remove all RAM ranges > + * as they are the ones that need to be dumped. > + * We still need all non-RAM information in order to do I/O. > + */ > + /* NOTE: if you use old kexec, please remove memmap=exactmap > + * which remove all ranges, not only RAM ranges. > + */ > + saved_max_pfn = e820_end_of_ram_pfn(); > + e820_remove_range(0, ULLONG_MAX, E820_RAM, 1); > + sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); > + printk(KERN_INFO "crash dump non-RAM map:\n"); > + e820_print_map("crash_dump"); > +} > +#endif > + > static void __init memblock_x86_reserve_range_setup_data(void) > { > struct setup_data *data; > @@ -751,6 +770,9 @@ void __init setup_arch(char **cmdline_p) > parse_setup_data(); > /* update the e820_saved too */ > e820_reserve_setup_data(); > +#ifdef CONFIG_CRASH_DUMP > + e820_crashdump_remove_ram(); > +#endif > > copy_edd(); > > -- > 1.7.6 > > Best Regards! > > Jun Zhang > Inet: 8821-4273 > Dir.Tel: 86-21-6116-4273 > Email: jun.zhang@intel.com > > > -----Original Message----- > From: H. Peter Anvin [mailto:hpa@zytor.com] > Sent: Thursday, November 01, 2012 12:20 PM > To: Zhang, Jun > Cc: Thomas Gleixner; Ingo Molnar; x86@kernel.org; Andrew Morton; Fleming, Matt; Paul Gortmaker; linux-kernel@vger.kernel.org > Subject: RE: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG). > > 2) would make most sense to me, but I'd be okay with 3) as well. > > "Zhang, Jun" <jun.zhang@intel.com> wrote: > > >Hello, Anvin > > > >I want to explain why I modify in this place. In kexec, it pass three > >parameters, memmap=exactmap memmap=544K@64K memmap=64964K@32768K I > >think my patch modify the least code. > >Actually, there are some choise to fix it. > >1) my patch. > >2) modify kexec, only pass two parameters -- memmap=544K@64K > >memmap=64964K@32768K, in kernel setup_memory_map, we can remove RAM > >range. > >3) add extra optional, like memmap=REMOVERAM > > > >Which one do you like? Maybe you have better solution, please share it. > >Thanks! > > > >Best Regards! > > > >Jun Zhang > >Inet: 8821-4273 > >Dir.Tel: 86-21-6116-4273 > >Email: jun.zhang@intel.com > > > >-----Original Message----- > >From: H. Peter Anvin [mailto:hpa@zytor.com] > >Sent: Wednesday, October 31, 2012 1:39 PM > >To: Zhang, Jun > >Cc: Thomas Gleixner; Ingo Molnar; x86@kernel.org; Andrew Morton; > >Fleming, Matt; Paul Gortmaker; linux-kernel@vger.kernel.org > >Subject: Re: [PATCH] To crash dump, we need keep other memory type > >except E820_RAM, because other type come from BIOS or firmware is used > >by other code(for example: PCI_MMCONFIG). > > > >On 10/30/2012 10:22 PM, Zhang, Jun wrote: > >> Hello, Anvin > >> You are right. Thanks! > >> > >> Hello, All > >> Please review it again. Thanks! > >> > >> From bf7506ac7e9ce0df0b915164dbb7a6d858ef2e40 Mon Sep 17 00:00:00 > >> 2001 > >> From: jzha144 <jun.zhang@intel.com> > >> Date: Wed, 31 Oct 2012 08:51:18 +0800 > >> Subject: [PATCH] When we are doing a crash dump, we still need > >non-E820_RAM > >> memory type address information in order to do I/O. so only > >> remove all RAM ranges which need to be dumped. > >> > >> Signed-off-by: jzha144 <jun.zhang@intel.com> > >> --- > >> arch/x86/kernel/e820.c | 9 +++++++++ > >> 1 files changed, 9 insertions(+), 0 deletions(-) > >> > >> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index > >> df06ade..77be839 100644 > >> --- a/arch/x86/kernel/e820.c > >> +++ b/arch/x86/kernel/e820.c > >> @@ -851,6 +851,15 @@ static int __init parse_memmap_opt(char *p) > >> * reset. > >> */ > >> saved_max_pfn = e820_end_of_ram_pfn(); > >> + > >> + /* > >> + * We are doing a crash dump, so remove all RAM ranges > >> + * as they are the ones that need to be dumped. > >> + * We still need all non-RAM information in order to do I/O. > >> + */ > >> + e820_remove_range(0, ULLONG_MAX, E820_RAM, 1); > >> + userdef = 1; > >> + return 0; > >> #endif > >> e820.nr_map = 0; > >> userdef = 1; > >> > > > >The code is still wrong... > > > > -hpa > > > > > >-- > >H. Peter Anvin, Intel Open Source Technology Center I work for Intel. > >I don't speak on their behalf. > > -- > Sent from my mobile phone. Please excuse brevity and lack of formatting. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG). 2012-11-01 8:49 ` Zhang, Jun 2012-11-02 15:08 ` Paul Gortmaker @ 2012-11-02 16:37 ` H. Peter Anvin 2012-11-05 1:37 ` [PATCH] crash dump: don't delete non-E820_RAM during init Zhang, Jun 1 sibling, 1 reply; 15+ messages in thread From: H. Peter Anvin @ 2012-11-02 16:37 UTC (permalink / raw) To: Zhang, Jun Cc: Thomas Gleixner, Ingo Molnar, x86@kernel.org, Andrew Morton, Fleming, Matt, Paul Gortmaker, linux-kernel@vger.kernel.org On 11/01/2012 01:49 AM, Zhang, Jun wrote: > Hello, Anvin > > Thank for your advice. > > Hello, All > > the next patch is made by 2), please review it. Thanks! > No, it is not. You are still modifying the behavior of the kernel depending on CONFIG_CRASH_DUMP. CONFIG_CRASH_DUMP doesn't mean "we are doing a crash dump". It means "it is possible to use this kernel to do a crash dump". Either you are using standard kernel parameters in a standard way which is what option 2 was supposed to be -- it should require no kernel changes! -- or you have to put something in a code path specific to a crash dump. -hpa ^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: [PATCH] crash dump: don't delete non-E820_RAM during init 2012-11-02 16:37 ` H. Peter Anvin @ 2012-11-05 1:37 ` Zhang, Jun 2012-11-05 2:39 ` H. Peter Anvin 0 siblings, 1 reply; 15+ messages in thread From: Zhang, Jun @ 2012-11-05 1:37 UTC (permalink / raw) To: H. Peter Anvin Cc: Thomas Gleixner, Ingo Molnar, x86@kernel.org, Andrew Morton, Fleming, Matt, Paul Gortmaker, linux-kernel@vger.kernel.org [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2025 bytes --] Hello, Gortmaker I will modify my subject. Thanks! Hello, Anvin from our three options, I think third option is better. But in 3) option, there are two choose, 3.1) is like memmap=REMOVERAM, 3.2) is memmap=CRASHKDUMP. In 3.1) we maybe need ifdef/endif within the { } of the function (like exactmap). In 3.2) we can remove the ifdef/endif. Which one is the better? Maybe you have a better solution, please share it. Thanks! Next is our three option. 1) my patch. 2) modify kexec, only pass two parameters -- memmap=544K@64K memmap=64964K@32768K, in kernel setup_memory_map, we can remove RAM range. 3) add extra optional, 3.1) like memmap=REMOVERAM 3.2) like memmap=CRASHKDUMP Best Regards! Jun Zhang Inet: 8821-4273 Dir.Tel: 86-21-6116-4273 Email: jun.zhang@intel.com -----Original Message----- From: H. Peter Anvin [mailto:hpa@zytor.com] Sent: Saturday, November 03, 2012 12:38 AM To: Zhang, Jun Cc: Thomas Gleixner; Ingo Molnar; x86@kernel.org; Andrew Morton; Fleming, Matt; Paul Gortmaker; linux-kernel@vger.kernel.org Subject: Re: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG). On 11/01/2012 01:49 AM, Zhang, Jun wrote: > Hello, Anvin > > Thank for your advice. > > Hello, All > > the next patch is made by 2), please review it. Thanks! > No, it is not. You are still modifying the behavior of the kernel depending on CONFIG_CRASH_DUMP. CONFIG_CRASH_DUMP doesn't mean "we are doing a crash dump". It means "it is possible to use this kernel to do a crash dump". Either you are using standard kernel parameters in a standard way which is what option 2 was supposed to be -- it should require no kernel changes! -- or you have to put something in a code path specific to a crash dump. -hpa ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] crash dump: don't delete non-E820_RAM during init 2012-11-05 1:37 ` [PATCH] crash dump: don't delete non-E820_RAM during init Zhang, Jun @ 2012-11-05 2:39 ` H. Peter Anvin 2012-11-05 2:57 ` Zhang, Jun 0 siblings, 1 reply; 15+ messages in thread From: H. Peter Anvin @ 2012-11-05 2:39 UTC (permalink / raw) To: Zhang, Jun Cc: Thomas Gleixner, Ingo Molnar, x86@kernel.org, Andrew Morton, Fleming, Matt, Paul Gortmaker, linux-kernel@vger.kernel.org On 11/05/2012 02:37 AM, Zhang, Jun wrote: > Hello, Gortmaker > I will modify my subject. Thanks! > > Hello, Anvin > from our three options, I think third option is better. But in 3) option, there are two choose, 3.1) is like memmap=REMOVERAM, 3.2) is memmap=CRASHKDUMP. > In 3.1) we maybe need ifdef/endif within the { } of the function (like exactmap). > In 3.2) we can remove the ifdef/endif. > Which one is the better? Maybe you have a better solution, please share it. > Thanks! > > Next is our three option. > 1) my patch. > 2) modify kexec, only pass two parameters -- memmap=544K@64K > memmap=64964K@32768K, in kernel setup_memory_map, we can remove RAM > range. > 3) add extra optional, 3.1) like memmap=REMOVERAM > 3.2) like memmap=CRASHKDUMP > Again, 2 would be better because it is a localized change to kexec. If that works I don't see why there is any reason to change anything else. -hpa ^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: [PATCH] crash dump: don't delete non-E820_RAM during init 2012-11-05 2:39 ` H. Peter Anvin @ 2012-11-05 2:57 ` Zhang, Jun 2012-11-05 2:59 ` H. Peter Anvin 0 siblings, 1 reply; 15+ messages in thread From: Zhang, Jun @ 2012-11-05 2:57 UTC (permalink / raw) To: H. Peter Anvin Cc: Thomas Gleixner, Ingo Molnar, x86@kernel.org, Andrew Morton, Fleming, Matt, Paul Gortmaker, linux-kernel@vger.kernel.org [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1809 bytes --] Hello, Anvin 1) use "memmap=exactmap", which remove all ranges include ram and non-ram range. So my first patch reserve the non-ram range. 2)don't use " memmap=exactmap ", so it reserve all ranges. But we only need non-ram, so we need kernel to remove RAM, just as my second patch. Best Regards! Jun Zhang Inet: 8821-4273 Dir.Tel: 86-21-6116-4273 Email: jun.zhang@intel.com -----Original Message----- From: H. Peter Anvin [mailto:hpa@zytor.com] Sent: Monday, November 05, 2012 10:39 AM To: Zhang, Jun Cc: Thomas Gleixner; Ingo Molnar; x86@kernel.org; Andrew Morton; Fleming, Matt; Paul Gortmaker; linux-kernel@vger.kernel.org Subject: Re: [PATCH] crash dump: don't delete non-E820_RAM during init On 11/05/2012 02:37 AM, Zhang, Jun wrote: > Hello, Gortmaker > I will modify my subject. Thanks! > > Hello, Anvin > from our three options, I think third option is better. But in 3) option, there are two choose, 3.1) is like memmap=REMOVERAM, 3.2) is memmap=CRASHKDUMP. > In 3.1) we maybe need ifdef/endif within the { } of the function (like exactmap). > In 3.2) we can remove the ifdef/endif. > Which one is the better? Maybe you have a better solution, please share it. > Thanks! > > Next is our three option. > 1) my patch. > 2) modify kexec, only pass two parameters -- memmap=544K@64K > memmap=64964K@32768K, in kernel setup_memory_map, we can remove RAM > range. > 3) add extra optional, 3.1) like memmap=REMOVERAM > 3.2) like memmap=CRASHKDUMP > Again, 2 would be better because it is a localized change to kexec. If that works I don't see why there is any reason to change anything else. -hpa ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] crash dump: don't delete non-E820_RAM during init 2012-11-05 2:57 ` Zhang, Jun @ 2012-11-05 2:59 ` H. Peter Anvin 0 siblings, 0 replies; 15+ messages in thread From: H. Peter Anvin @ 2012-11-05 2:59 UTC (permalink / raw) To: Zhang, Jun Cc: Thomas Gleixner, Ingo Molnar, x86@kernel.org, Andrew Morton, Fleming, Matt, Paul Gortmaker, linux-kernel@vger.kernel.org On 11/05/2012 03:57 AM, Zhang, Jun wrote: > Hello, Anvin > 1) use "memmap=exactmap", which remove all ranges include ram and non-ram range. So my first patch reserve the non-ram range. > 2)don't use " memmap=exactmap ", so it reserve all ranges. But we only need non-ram, so we need kernel to remove RAM, just as my second patch. Sorry, you have completely lost me now. You seem to be contradicting yourself from one message to another. -hpa ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2012-11-05 2:59 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-10-31 1:26 [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG) Zhang, Jun 2012-10-31 2:46 ` H. Peter Anvin 2012-10-31 3:39 ` Zhang, Jun 2012-10-31 4:38 ` H. Peter Anvin 2012-10-31 5:22 ` Zhang, Jun 2012-10-31 5:38 ` H. Peter Anvin 2012-11-01 2:15 ` Zhang, Jun 2012-11-01 4:20 ` H. Peter Anvin 2012-11-01 8:49 ` Zhang, Jun 2012-11-02 15:08 ` Paul Gortmaker 2012-11-02 16:37 ` H. Peter Anvin 2012-11-05 1:37 ` [PATCH] crash dump: don't delete non-E820_RAM during init Zhang, Jun 2012-11-05 2:39 ` H. Peter Anvin 2012-11-05 2:57 ` Zhang, Jun 2012-11-05 2:59 ` H. Peter Anvin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).