headers
Michael Ellerman | 1 May 2008 01:16
Picon
Gravatar

Re: [PATCH] Make extended crashkernel= syntax less confusing

On Wed, 2008-04-30 at 11:29 -0700, Andrew Morton wrote:
> On Wed, 30 Apr 2008 11:36:27 +1000 (EST)
> Michael Ellerman <michael@...> wrote:
> 
> > The extended crashkernel syntax is a little confusing in the
> > way it handles ranges. eg:
> > 
> >  crashkernel=512M-2G:64M,2G-:128M
> > 
> > Means if the machine has between 512M and 2G of memory the
> > crash region should be 64M, and if the machine has 2G of
> > memory the region should be 64M. Only if the machine has
> > more than 2G memory will 128M be allocated.
> > 
> > Although that semantic is correct, it is somewhat baffling.
> > Instead I propose that the end of the range means the first
> > address past the end of the range, ie: 512M up to but not
> > including 2G.
> > 
> > Signed-off-by: Michael Ellerman <michael@...>
> > Acked-by: Bernhard Walle <bwalle@...>
> > ---
> > 
> >  kernel/kexec.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/kernel/kexec.c b/kernel/kexec.c
> > index 6782dce..0ab5e33 100644
> > --- a/kernel/kexec.c
> > +++ b/kernel/kexec.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Horman | 1 May 2008 02:16
Picon
Gravatar

Re: [PATCH] Make extended crashkernel= syntax less confusing

On Wed, Apr 30, 2008 at 11:57:26PM +0200, Bernhard Walle wrote:
> * Andrew Morton <akpm@...> [2008-04-30 11:29]:
> >
> > I'm a bit surprised to see the code being updated but not the
> > documentation.  Were they out of sync before or are they out of sync after
> > this patch or were they always in sync or what?
> 
> It was simply not specified. I propose the following patch to make it
> clear:

This is fine by me, acked.

> ----
> 
> [PATCH] Clarify inclusive/exclusive in crashkernel commandline in documentation
> 
> 
> Reflect the changes from Michael Ellerman in crashkernel syntax that make the
> end of the memory exclusive in the documentation. It was simply not specified
> before.
> 
> 
> Signed-off-by: Bernhard Walle <bwalle@...>
> 
> ---
>  Documentation/kdump/kdump.txt |    5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> --- a/Documentation/kdump/kdump.txt
> +++ b/Documentation/kdump/kdump.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lombard, David N | 5 May 2008 22:53
Picon

[PATCH] Cross compile?

In util/Makefile, the bin-to-hex utility was being built with the
cross-compiler, not the host compiler.  This patch fixes that.

Signed-off-by: David N. Lombard, <david.n.lombard@...>

--- kexec-tools-testing-20080324/util/Makefile.orig	2008-03-24 01:30:57.000000000 -0700
+++ kexec-tools-testing-20080324/util/Makefile	2008-05-05 13:10:09.000000000 -0700
 <at>  <at>  -2,10 +2,7  <at>  <at>  BIN_TO_HEX:= bin/bin-to-hex

 $(BIN_TO_HEX): $(srcdir)/util/bin-to-hex.c
 	 <at> $(MKDIR) -p $( <at> D)
-	$(LINK.o) -o $ <at>  $^
+	$(BUILD_CC) $(BUILD_CFLAGS) -o $ <at>  $<
-
-$(BIN_TO_HEX): CC=$(BUILD_CC)
-$(BIN_TO_HEX): CFLAGS=$(BUILD_CFLAGS)

 dist += util/Makefile util/bin-to-hex.c
 clean += util/bin-to-hex.o $(BIN_TO_HEX)
Permalink | Reply | 12 comments |
headers
Jeremy Kerr | 5 May 2008 23:42
Favicon

Re: [PATCH] Cross compile?

David,

> In util/Makefile, the bin-to-hex utility was being built with the
> cross-compiler, not the host compiler.  This patch fixes that.

We set the CC to BUILD_CC for the bin-to-hex target so it should use the 
host compiler currently.

What are your BUILD_CC, BUILD_CFLAGS and LDFLAGS?

Cheers,

Jeremy
Permalink | Reply | 11 comments |
headers
Lombard, David N | 6 May 2008 15:31
Picon

Re: [PATCH] Cross compile?

On Tue, May 06, 2008 at 07:42:45AM +1000, Jeremy Kerr wrote:
> David,
> 
> > In util/Makefile, the bin-to-hex utility was being built with the
> > cross-compiler, not the host compiler.  This patch fixes that.
> 
> We set the CC to BUILD_CC for the bin-to-hex target so it should use the 
> host compiler currently.
> 
> What are your BUILD_CC, BUILD_CFLAGS and LDFLAGS?

Well, note the patch *does* uses those values--it's just the assignment
doesn't work.

--

-- 
David N. Lombard, Intel, Irvine, CA
I do not speak for Intel Corporation; all comments are strictly my own.
Permalink | Reply | 10 comments |
headers
Jeremy Kerr | 7 May 2008 00:42
Favicon

Re: [PATCH] Cross compile?

Hi David,

> Well, note the patch *does* uses those values--it's just the
> assignment doesn't work.

Let's fix the assignment then - it's been working fine here (build = 
i386-linux, host = powerpc-linux, target = powerpc64-linux), so I'd 
like to know what's breaking on your system.

What are you using for CC, BUILD_CC and LDFLAGS?

Cheers,

Jeremy
Permalink | Reply | 9 comments |
headers
Lombard, David N | 7 May 2008 17:09
Picon

Re: [PATCH] Cross compile?

On Wed, May 07, 2008 at 08:42:22AM +1000, Jeremy Kerr wrote:
> Hi David,
> 
> > Well, note the patch *does* uses those values--it's just the
> > assignment doesn't work.
> 
> Let's fix the assignment then - it's been working fine here (build = 
> i386-linux, host = powerpc-linux, target = powerpc64-linux), so I'd 
> like to know what's breaking on your system.
> 
> What are you using for CC, BUILD_CC and LDFLAGS?

  # Compiler for building kexec
  CC              = uclibc-gcc
  CPP             = uclibc-gcc -E
  LD              = ld
  AS              = as
  OBJCOPY         = objcopy
  AR              = ar

  # C compiler for binaries to run during the build
  BUILD_CC        = host-gcc
  BUILD_CFLAGS    = -O2 -Wall
  TARGET_CC       = uclibc-gcc
  TARGET_CFLAGS   = -O2 -Wall

--

-- 
David N. Lombard, Intel, Irvine, CA
I do not speak for Intel Corporation; all comments are strictly my own.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Lombard, David N | 7 May 2008 17:39
Picon

Re: [PATCH] Cross compile?

On Wed, May 07, 2008 at 08:09:32AM -0700, Lombard, David N wrote:
> On Wed, May 07, 2008 at 08:42:22AM +1000, Jeremy Kerr wrote:
> > Hi David,
> > 
> > > Well, note the patch *does* uses those values--it's just the
> > > assignment doesn't work.
> > 
> > Let's fix the assignment then - it's been working fine here (build = 
> > i386-linux, host = powerpc-linux, target = powerpc64-linux), so I'd 
> > like to know what's breaking on your system.

More info:

Failure (original):

 mkdir -p purgatory
 uclibc-gcc  --no-undefined -nostartfiles -nostdlib -nodefaultlibs -e purgatory_start -r -o
purgatory/purgatory.ro purgatory/purgatory.o purgatory/printf.o purgatory/string.o
purgatory/arch/i386/entry32-16.o purgatory/arch/i386/entry32-16-debug.o
purgatory/arch/i386/entry32.o purgatory/arch/i386/setup-x86.o purgatory/arch/i386/stack.o
purgatory/arch/i386/compat_x86_64.o purgatory/arch/i386/purgatory-x86.o
purgatory/arch/i386/console-x86.o purgatory/arch/i386/vga.o purgatory/arch/i386/pic.o
purgatory/arch/i386/crashdump_backup.o purgatory/sha256.o
 uclibc-gcc   -o bin/bin-to-hex util/bin-to-hex.c
 mkdir -p kexec
 bin/bin-to-hex purgatory < purgatory/purgatory.ro > kexec/purgatory.c
 /bin/sh: bin/bin-to-hex: /lib/ld-uClibc.so.0: bad ELF interpreter: No such file or directory
 make[1]: *** [kexec/purgatory.c] Error 126

Success (patched):
(Continue reading)

Permalink | Reply | 7 comments |
headers
Lombard, David N | 7 May 2008 19:11
Picon

Reducing the size of kexec util

The current (20080324) kexec binary on x86 is 135KiB.  While not a
problem on a normal distro or runtime environment, it's a chubster
in an embedded role.

Has any thought been given to reducing its 'on-disk' footprint?
The rather obvious, non-default build-time options to only support
specific kernel types and capabilities, jumps to mind.

Beyond build-time options, a Busybox applet would further minimize
size, but maintenance would be painful...

--

-- 
David N. Lombard, Intel, Irvine, CA
I do not speak for Intel Corporation; all comments are strictly my own.
Permalink | Reply | 4 comments |
headers
Neil Horman | 7 May 2008 19:28
Picon
Favicon

Re: Reducing the size of kexec util

On Wed, May 07, 2008 at 10:11:30AM -0700, Lombard, David N wrote:
> The current (20080324) kexec binary on x86 is 135KiB.  While not a
> problem on a normal distro or runtime environment, it's a chubster
> in an embedded role.
> 
> Has any thought been given to reducing its 'on-disk' footprint?
> The rather obvious, non-default build-time options to only support
> specific kernel types and capabilities, jumps to mind.
> 
> Beyond build-time options, a Busybox applet would further minimize
> size, but maintenance would be painful...
> 
Busybox is precisely what I use to implement kdump in RHEL at the moment.  Its
still a bit bloated, since it is meant for enterprise servers, but it makes it
very easy to customize very small initramfs files for specific purposes.

Neil

> -- 
> David N. Lombard, Intel, Irvine, CA
> I do not speak for Intel Corporation; all comments are strictly my own.
> 
> _______________________________________________
> kexec mailing list
> kexec@...
> http://lists.infradead.org/mailman/listinfo/kexec

--

-- 
/***************************************************
 *Neil Horman
(Continue reading)

Permalink | Reply | 3 comments |

Gmane