headers
Ken'ichi Ohmichi | 9 Jul 2008 02:25
Picon
Picon

Re: [PATCH] Use progress bar also for bitmap creation


Hi Bernhard,

Bernhard Walle wrote:
> * Ken'ichi Ohmichi [2008-07-07 11:50]:
>> Ken'ichi Ohmichi wrote:
>>> Hi Bernhard,
>>>
>>> Thank you for your patch.
>>> I like this idea :-)
>>>
>>> I am busy now, and I will consider the patch well the next week.
>> Thank you for the patch, and sorry for my late response.
>>
>> I added the progress bar for excluding free pages to your patch.
>> Could you please check the attached patch ?
>> If there is no problem in the attached patch, I will release the
>> next release with this patch.
> 
> I also tested on a larger SGI machine. Here the exclusion of the memory
> holes takes a considerable amount of time. Therefore, I would suggest
> to also use the patch below:

Thank you for the patch.
It sounds good to me.
I'll merge it into the next release.

Thanks
Ken'ichi Ohmichi
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Horman | 9 Jul 2008 02:41
Picon
Gravatar

Re: [PATCH 2/3] Remove redundancy between get_memory_ranges_proc_iomem() and get_memory_ranges_sysfs()

On Mon, Jul 07, 2008 at 04:43:41PM +0200, Bernhard Walle wrote:
> With the previous patch, we have a duplication between that both functions
> for following tasks:
> 
>  - don't report the interrupt table as RAM,
>  - set the mem_min and mem_max limits for kdump.
> 
> This patch removes that redundancy into the function get_memory_ranges()
> that calls both functions internally.

Hi Bernhard,

these patches seem fine to me, but I am still having minor troubles
with missing defines. For the record, I am seeing the problems with
gcc-3.4.5 + glibc-2.3.6. Yes, I know this is old, but it would
be nice if this minor issue didn't break it.

1. The snippet below looks good, but it needs to be included
   in or berfore " [PATCH 1/3] Parse /sys/firmware/memmap".

> diff --git a/kexec/firmware_memmap.c b/kexec/firmware_memmap.c
> index cdac6f3..2ad450d 100644
> --- a/kexec/firmware_memmap.c
> +++ b/kexec/firmware_memmap.c
>  <at>  <at>  -31,6 +31,13  <at>  <at> 
>  #include "firmware_memmap.h"
>  #include "kexec.h"
>  
> +/*
> + * If the system is too old for ULLONG_MAX, define it here.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Huang Ying | 9 Jul 2008 03:09
Picon
Favicon

Re: [PATCH -mm 1/2] kexec jump -v12: kexec jump

On Tue, 2008-07-08 at 10:50 -0400, Vivek Goyal wrote:
> On Mon, Jul 07, 2008 at 11:25:22AM +0800, Huang Ying wrote:
> > This patch provides an enhancement to kexec/kdump. It implements
> > the following features:
> > 
> > - Backup/restore memory used by the original kernel before/after
> >   kexec.
> > 
> > - Save/restore CPU state before/after kexec.
> > 
> 
> Hi Huang,
> 
> In general this patch set looks good enough to live in -mm and
> get some testing going.
> 
> To me, adding capability to return back to original kernel looks
> like a logical extension to kexec functionality.
> 
> Acked-by: Vivek Goyal <vgoyal@...>
> 
> Few minor comments inline.

Thank you very much!

> [..]
> > --- a/arch/x86/kernel/machine_kexec_32.c
> > +++ b/arch/x86/kernel/machine_kexec_32.c
> >  <at>  <at>  -22,6 +22,7  <at>  <at> 
> >  #include <asm/cpufeature.h>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Huang Ying | 9 Jul 2008 03:12
Picon
Favicon

Re: [PATCH -mm 1/2] kexec jump -v12: kexec jump

Hi, Pavel,

On Tue, 2008-07-08 at 12:40 +0200, Pavel Machek wrote:
> Hi!
> 
> > > >  <at>  <at>  -1411,3 +1421,50  <at>  <at>  static int __init crash_save_vmcoreinfo_
> > > >  }
> > > > 
> > > >  module_init(crash_save_vmcoreinfo_init)
> > > > +
> > > > +/**
> > > > + *   kernel_kexec - reboot the system
> > 
> > > Really?
> > 
> > I will change the comments to reflect the changes to kernel_kexec.
> > 
> > > > + *   Move into place and start executing a preloaded standalone
> > > > + *   executable.  If nothing was preloaded return an error.
> > > > + */
> > > > +int kernel_kexec(void)
> > > > +{
> > > > +     int error = 0;
> > > > +
> > > > +     if (xchg(&kexec_lock, 1))
> > > > +             return -EBUSY;
> > > 
> > > That's quite a strange way to provide a lock. mutex_trylock?
> > 
> > I think this is because kexec_lock is used by crash_kexec() too, which
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernhard Walle | 9 Jul 2008 13:10
Picon

Parse /sys/firmware/memmap

Define ULLONG_MAX and define LLONG_MAX. Both now in the first patch.  The rest
is the same.
Permalink | Reply | 0 comments |
headers
Bernhard Walle | 9 Jul 2008 13:11
Picon

[PATCH 2/3] Remove redundancy between get_memory_ranges_proc_iomem() and get_memory_ranges_sysfs()

With the previous patch, we have a duplication between that both functions
for following tasks:

 - don't report the interrupt table as RAM,
 - set the mem_min and mem_max limits for kdump.

This patch removes that redundancy into the function get_memory_ranges()
that calls both functions internally.

Signed-off-by: Bernhard Walle <bwalle@...>
---
 kexec/arch/i386/kexec-x86.c |   96 ++++++++++++++++---------------------------
 1 files changed, 36 insertions(+), 60 deletions(-)

diff --git a/kexec/arch/i386/kexec-x86.c b/kexec/arch/i386/kexec-x86.c
index 554c154..d5b6737 100644
--- a/kexec/arch/i386/kexec-x86.c
+++ b/kexec/arch/i386/kexec-x86.c
 <at>  <at>  -41,13 +41,10  <at>  <at>  static struct memory_range memory_range[MAX_MEMORY_RANGES];
  *  <at> param[out] range pointer that will be set to an array that holds the
  *             memory ranges
  *  <at> param[out] ranges number of ranges valid in  <at> p range
- *  <at> param[in]  kexec_flags the kexec_flags to determine if we load a normal
- *             or a crashdump kernel
  *
  *  <at> return 0 on success, any other value on failure.
  */
-static int get_memory_ranges_proc_iomem(struct memory_range **range, int *ranges,
-					unsigned long kexec_flags)
+static int get_memory_ranges_proc_iomem(struct memory_range **range, int *ranges)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernhard Walle | 9 Jul 2008 13:11
Picon

[PATCH 1/3] Parse /sys/firmware/memmap.

After the patch that provides /sys/firmware/memmap has been merged in the 'tip'
tree by Ingo Molnar, kexec should use that interface.

This patch implements architecture-independent parsing in a new file called
firmware_memmap.c. The x86 part is ported to use that memory map for
kexec. We don't use that memory map for building the ELF core headers,
that was the intention for that new interface.

Signed-off-by: Bernhard Walle <bwalle@...>
---
 kexec/Makefile              |    1 +
 kexec/arch/i386/kexec-x86.c |  124 +++++++++++++++++++-
 kexec/firmware_memmap.c     |  278 +++++++++++++++++++++++++++++++++++++++++++
 kexec/firmware_memmap.h     |   63 ++++++++++
 4 files changed, 463 insertions(+), 3 deletions(-)
 create mode 100644 kexec/firmware_memmap.c
 create mode 100644 kexec/firmware_memmap.h

diff --git a/kexec/Makefile b/kexec/Makefile
index a80b940..3a00114 100644
--- a/kexec/Makefile
+++ b/kexec/Makefile
 <at>  <at>  -18,6 +18,7  <at>  <at>  KEXEC_SRCS += kexec/kexec-elf-core.c
 KEXEC_SRCS += kexec/kexec-elf-rel.c
 KEXEC_SRCS += kexec/kexec-elf-boot.c
 KEXEC_SRCS += kexec/kexec-iomem.c
+KEXEC_SRCS += kexec/firmware_memmap.c
 KEXEC_SRCS += kexec/crashdump.c
 KEXEC_SRCS += kexec/crashdump-xen.c
 KEXEC_SRCS += kexec/phys_arch.c
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bernhard Walle | 9 Jul 2008 13:11
Picon

[PATCH 3/3] Use get_memory_ranges() on x86-64.

Because the get_memory_ranges() function was the same on i386 and x86_64, and
because that /sys/firmware/memmap interface should also be used for x86_64
without *new* code duplication, that part was moved out in a new file called
kexec-x86-common.c. That file only contains the memory map parsing for both the
"old" /proc/iomem interface and the new /sys/firmware/memmap interface.

That file is now built for i386 and x86_64.

Signed-off-by: Bernhard Walle <bwalle@...>
---
 kexec/arch/i386/Makefile           |    1 +
 kexec/arch/i386/kexec-x86-common.c |  207 ++++++++++++++++++++++++++++++++++++
 kexec/arch/i386/kexec-x86.c        |  175 ------------------------------
 kexec/arch/x86_64/Makefile         |    1 +
 kexec/arch/x86_64/kexec-x86_64.c   |   83 --------------
 5 files changed, 209 insertions(+), 258 deletions(-)
 create mode 100644 kexec/arch/i386/kexec-x86-common.c

diff --git a/kexec/arch/i386/Makefile b/kexec/arch/i386/Makefile
index f2d9636..d52a2f5 100644
--- a/kexec/arch/i386/Makefile
+++ b/kexec/arch/i386/Makefile
 <at>  <at>  -2,6 +2,7  <at>  <at> 
 # kexec i386 (linux booting linux)
 #
 i386_KEXEC_SRCS =  kexec/arch/i386/kexec-x86.c
+i386_KEXEC_SRCS += kexec/arch/i386/kexec-x86-common.c
 i386_KEXEC_SRCS += kexec/arch/i386/kexec-elf-x86.c
 i386_KEXEC_SRCS += kexec/arch/i386/kexec-elf-rel-x86.c
 i386_KEXEC_SRCS += kexec/arch/i386/kexec-bzImage.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernhard Walle | 9 Jul 2008 13:12
X-Face
Picon

Re: [PATCH 2/3] Remove redundancy between get_memory_ranges_proc_iomem() and get_memory_ranges_sysfs()

Hi,

* Simon Horman [2008-07-09 10:41]:
>
> On Mon, Jul 07, 2008 at 04:43:41PM +0200, Bernhard Walle wrote:
> > With the previous patch, we have a duplication between that both functions
> > for following tasks:
> > 
> >  - don't report the interrupt table as RAM,
> >  - set the mem_min and mem_max limits for kdump.
> > 
> > This patch removes that redundancy into the function get_memory_ranges()
> > that calls both functions internally.
> 
> these patches seem fine to me, but I am still having minor troubles
> with missing defines. For the record, I am seeing the problems with
> gcc-3.4.5 + glibc-2.3.6. Yes, I know this is old, but it would
> be nice if this minor issue didn't break it.

Yes, of course, I just cannot reproduce it, even with current Debian
and gcc 3.4 ...

> 1. The snippet below looks good, but it needs to be included
>    in or berfore " [PATCH 1/3] Parse /sys/firmware/memmap".

Should be fixed now.

> > diff --git a/kexec/firmware_memmap.c b/kexec/firmware_memmap.c
> > index cdac6f3..2ad450d 100644
> > --- a/kexec/firmware_memmap.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernhard Walle | 9 Jul 2008 13:48
X-Face
Picon

[PATCH] makedumpfile: Improve error handing when SIZE(nodemask_t) is undefined

Hi,

I accidentally used a new makedumpfile with an old VMCOREINFO that did
not contain the SIZE(nodemask_t). Then len was -1, and malloc(-1)
failed. Which looked like memory was too low.

This patch just improves the error message in that case so that the
user knows what is wrong.

Signed-off-by: Bernhard Walle <bwalle@...>

---
 makedumpfile.c |    5 +++++
 1 file changed, 5 insertions(+)

diff -u -r1.7.2.37 makedumpfile.c
--- makedumpfile.c	9 Jul 2008 00:22:09 -0000	1.7.2.37
+++ makedumpfile.c	9 Jul 2008 11:39:43 -0000
 <at>  <at>  -2580,6 +2580,11  <at>  <at> 
 	    && (SYMBOL(node_states) == NOT_FOUND_SYMBOL))
 		return 0;

+	if (SIZE(nodemask_t) == NOT_FOUND_LONG_VALUE) {
+		ERRMSG("SIZE(nodemask_t) undefined.\n");
+		return 0;
+	}
+
 	len = SIZE(nodemask_t);
 	vt.node_online_map_len = len/sizeof(unsigned long);
 	if (!(vt.node_online_map = (unsigned long *)malloc(len))) {
(Continue reading)

Permalink | Reply | 6 comments |

Gmane