On Mon, Feb 03, 2014 at 06:54:52PM +0100, Dirk Müller wrote:
strncat() does not want the total size but the maximum length.
Signed-off-by: Dirk Mueller dmuel...@suse.com
---
kexec/fs2dt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kexec/fs2dt.c
On Fri, Jan 31, 2014 at 09:30:47AM -0500, Vivek Goyal wrote:
On Fri, Jan 31, 2014 at 02:23:04PM +0900, Simon Horman wrote:
[..]
Simon what do you think? A kexec-tools release every 4 months or every
6 months. Does it make sense to you?
Perhaps we could aim for every second kernel
On Fri, Jan 31, 2014 at 08:24:21AM +0530, Mahesh Jagannath Salgaonkar wrote:
On 01/24/2014 07:46 PM, Laurent Dufour wrote:
When the kernel is built with CONFIG_PPC_EARLY_DEBUG_OPAL set, it is
expecting to get r8 and r9 filled respectively with OPAL base address and
OPAL entry address
On Tue, Feb 04, 2014 at 01:03:42PM +0100, Dirk Müller wrote:
Hi Simon,
I don't think you need the -1 as filename will have a trailing '\0'
which is not counted in the return value of strlen()
Thats true, but strncat always writes a trailing NUL, and to avoid
that this one overflows the
On Tue, Feb 04, 2014 at 05:31:51PM +0900, Simon Horman wrote:
On Fri, Jan 31, 2014 at 09:30:47AM -0500, Vivek Goyal wrote:
On Fri, Jan 31, 2014 at 02:23:04PM +0900, Simon Horman wrote:
[..]
Simon what do you think? A kexec-tools release every 4 months or every
6 months. Does
Hi all,
I am happy to announce the release of kexec-tools 2.0.5.
The release can be downloaded from kernel.org:
http://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools-2.0.5.tar.xz
http://kernel.org/pub/linux/utils/kernel/kexec/
I have also tagged it in git:
On Wed, Feb 05, 2014 at 09:12:26AM +0800, Zhang Yanfei wrote:
On 02/04/2014 08:41 PM, Simon Horman wrote:
On Tue, Feb 04, 2014 at 05:31:51PM +0900, Simon Horman wrote:
On Fri, Jan 31, 2014 at 09:30:47AM -0500, Vivek Goyal wrote:
On Fri, Jan 31, 2014 at 02:23:04PM +0900, Simon Horman wrote
On Thu, Jan 30, 2014 at 04:32:03PM +0100, Laurent Dufour wrote:
RTAS is expecting parameters in Big Endian order so we have to byte swap
them in LE mode.
In the purgatory RTAS calls are only made for debug output.
Signed-off-by: Laurent Dufour lduf...@linux.vnet.ibm.com
Thanks, applied.
On Thu, Jan 30, 2014 at 04:06:22PM +0100, Laurent Dufour wrote:
All the attributes exposed in the device tree are in Big Endian format.
This patch add the byte swap operation for some entries which were not yet
processed, including those fixed by the following kernel's patch :
On Wed, Jan 29, 2014 at 09:23:11AM -0500, Vivek Goyal wrote:
On Wed, Jan 29, 2014 at 09:36:38AM +0800, Zhang Yanfei wrote:
Hello
On 01/29/2014 02:40 AM, Vivek Goyal wrote:
Hi All,
Just now we were discussing that fedora kexec-tools should rebase to
upstream kexec-tools every
On Tue, Jan 21, 2014 at 10:55:36AM +0800, Dave Young wrote:
Hi, Simon
The kernel patches has been merged into Linus tree, could you take a look
at these kexec-tools patches and merge them if there's no more comments?
Patch 4/4 was resended in a reply to original 4/4, the subject is:
On Tue, Jan 21, 2014 at 02:13:14PM +0800, Dave Young wrote:
On 01/21/14 at 02:07pm, Simon Horman wrote:
On Tue, Jan 21, 2014 at 10:55:36AM +0800, Dave Young wrote:
Hi, Simon
The kernel patches has been merged into Linus tree, could you take a look
at these kexec-tools patches
On Thu, Jan 16, 2014 at 08:39:06AM +1100, Peter Chubb wrote:
In the multiboot header, there is a field, `mem_lower' that is meant to
contain the size of memory starting at zero and ending below 640k.
If your kernel is compiled with CONFIG_X86_RESERVE_LOW non zero
(the usual case), then a
On Tue, Jan 14, 2014 at 04:26:24PM +0800, WANG Chao wrote:
Some sort of space like \t \n are used in kernel log. But we treat
them as non-printables and output \x20%x for each non-printable. So
let's fix it.
Signed-off-by: WANG Chao chaow...@redhat.com
Thanks, applied.
On Wed, Jan 15, 2014 at 01:25:49PM +1000, Peter Chubb wrote:
Hi Simon,
When you get a moment, please check out
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735360
Quick summary:
If your kernel is configured to protect the first few pages of
physical memory, then low memory
On Mon, Jan 13, 2014 at 01:29:44PM +0800, WANG Chao wrote:
On 01/06/14 at 02:14pm, Vivek Goyal wrote:
On Tue, Jan 07, 2014 at 01:37:34AM +0800, WANG Chao wrote:
It seems gcc doesn't check return type from inline function.
struct_val_u64() should return u64 otherwise upper 32bit is lost.
On Mon, Jan 13, 2014 at 12:47:25PM +0200, Taras Kondratyuk wrote:
From: Taras Kondratiuk taras.kondrat...@linaro.org
Currently little-endian ELFDATA is hard-coded in crashdump header.
This lead to a wrong header format if crashdump is generated on BE system.
Set native endianness into
On Fri, Dec 13, 2013 at 09:03:45AM +0100, Geert Uytterhoeven wrote:
Hi Simon,
On Fri, Dec 13, 2013 at 1:53 AM, Simon Horman ho...@verge.net.au wrote:
On Tue, Oct 15, 2013 at 07:50:57PM +0200, Geert Uytterhoeven wrote:
kexec support for Linux/m68k (tools part)
This is a set of patches
On Sun, Dec 01, 2013 at 12:40:27PM +0100, Geert Uytterhoeven wrote:
Hi Simon,
On Tue, Nov 5, 2013 at 8:05 AM, Simon Horman ho...@verge.net.au wrote:
On Sun, Nov 03, 2013 at 03:08:50PM +0100, Geert Uytterhoeven wrote:
On Wed, Oct 16, 2013 at 9:22 AM, Simon Horman ho...@verge.net.au wrote
On Tue, Oct 15, 2013 at 07:50:57PM +0200, Geert Uytterhoeven wrote:
kexec support for Linux/m68k (tools part)
This is a set of patches to add kexec support for m68k to kexec-tools.
- Kexec only, no kdump support yet (do you have enough RAM to keep a
crashdump kernel in memory at all
On Thu, Dec 12, 2013 at 12:18:56AM +, Geoff Levand wrote:
Hi Eric,
Here are a few minor fixes and improvements for kexec. Please consider.
FWIW,
Reviewed-by: Simon Horman ho...@verge.net.au
-Geoff
The following changes since commit 374b105797c3d4f29c685f3be535c35f5689b30e
On Fri, Dec 06, 2013 at 12:55:30AM +0530, Mahesh J Salgaonkar wrote:
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
A switchover from /kexec/arch/ppc64/fs2dt.c to common code under
/kexec/fs2dt.c broke the kdump on ppc64. The function add_usable_memory()
assumes that 'memory@*' node
a 32bit crash image.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: David Vrabel david.vra...@citrix.com
CC: Daniel Kiper daniel.ki...@oracle.com
CC: Simon Horman ho...@verge.net.au
CC: kexec@lists.infradead.org
Reviewed-by: Daniel Kiper daniel.ki...@oracle.com
Daniel
On Mon, Dec 02, 2013 at 08:06:23PM +0100, Daniel Kiper wrote:
Hi,
This patch series contains following minor Xen fixes and cleanups for
kexec-tools:
- kexec-tools/xen: Do not call xc_interface_close() if xc_interface_open()
failed,
- kexec-tools/xen: Remove redundant include.
On Tue, Nov 19, 2013 at 09:28:27AM +0100, Daniel Kiper wrote:
On Tue, Nov 19, 2013 at 10:20:14AM +0900, Simon Horman wrote:
On Wed, Nov 06, 2013 at 02:55:22PM +, David Vrabel wrote:
From: David Vrabel david.vra...@citrix.com
Xen 4.4 has an improvided kexec hypercall ABI that allows
On Fri, Nov 15, 2013 at 03:55:33PM +0100, Laurent Dufour wrote:
Following the commit 'b3c2962 fs2dt: Add a generic copy of fs2dt' which
introduced a generic fs2dt file, this patch is removing the ppc64
architecture's one.
Tests have been done successfully on Power 7 plateform.
On Fri, Nov 15, 2013 at 04:01:51PM +0100, Laurent Dufour wrote:
This patch provides support for the new Power PC litte endian (LE) mode. The
LE mode only differs in the way the instructions and data are stored in memory
thus there is no real need to duplicate the ppc64 code.
However some
On Wed, Nov 13, 2013 at 10:27:53AM +, David Vrabel wrote:
On 06/11/13 14:55, David Vrabel wrote:
The series adds support for the new hypercall ABI which should be
provided by Xen 4.4. Images are loaded into Xen directly with no
kernel involvement.
Please do not apply until the
know if I messed it up.
From: Simon Horman ho...@verge.net.au
[PATCH] kexec/xen: Correct some compile errors
Correct various problems introduced by
08cf823704b0fa3b (kexec/xen: directly load images images into Xen).
These all relate to the case here HAVE_LIBXENCTRL is not set.
Signed-off
On Wed, Nov 13, 2013 at 04:16:35PM +0100, Daniel Mack wrote:
Currently, kexec on arm assumes that it's safe to place binary images
such as atags, dtb or initrd at an estimated offset after the load
address. That estimated offset is set to 4 times the size of the
compressed image, hence
On Wed, Nov 06, 2013 at 02:55:19PM +, David Vrabel wrote:
From: David Vrabel david.vra...@citrix.com
libxc from Xen 4.4 added xc_kexec_load() which will be required to
load images into Xen in the future.
Remove all the #ifdef'ery for older versions of libxc.
Signed-off-by: David
On Sun, Nov 03, 2013 at 03:08:50PM +0100, Geert Uytterhoeven wrote:
On Wed, Oct 16, 2013 at 9:22 AM, Simon Horman ho...@verge.net.au wrote:
I've taken a quick look over this and it seems reasonable to me.
Thanks!
However, I wonder if I should wait for review of the kernel-side
On Thu, Oct 31, 2013 at 01:38:08PM +0800, WANG Chao wrote:
On 10/30/13 at 06:06pm, Lubomir Rintel wrote:
Hi,
On Wed, 2013-10-30 at 11:12 +0800, WANG Chao wrote:
On 09/19/13 at 04:49pm, Lubomir Rintel wrote:
Symbol name changed with the following commit:
62e32ac printk: rename
On Thu, Oct 31, 2013 at 09:27:45AM -0400, Vivek Goyal wrote:
On Wed, Oct 30, 2013 at 06:58:13PM -0600, jerry.hoem...@hp.com wrote:
[..]
Daisuke,
Are you planning on making changes to the kexec tools to automate
the setting of disable_cpu_apic to the capture kernel? Or do you
know
On Thu, Oct 31, 2013 at 09:42:32AM -0700, Taras Kondratiuk wrote:
On 10/30/2013 11:20 PM, Simon Horman wrote:
On Thu, Oct 31, 2013 at 01:38:08PM +0800, WANG Chao wrote:
On 10/30/13 at 06:06pm, Lubomir Rintel wrote:
Hi,
On Wed, 2013-10-30 at 11:12 +0800, WANG Chao wrote:
On 09/19/13
On Tue, Oct 29, 2013 at 10:36:36AM +0800, Dave Young wrote:
On 10/29/13 at 11:04am, Simon Horman wrote:
On Mon, Oct 28, 2013 at 12:10:40PM -0400, Vivek Goyal wrote:
On Mon, Oct 28, 2013 at 10:51:19AM +, Matthew Garrett wrote:
On Mon, Oct 28, 2013 at 06:45:32PM +0800, Dave Young wrote
On Mon, Oct 28, 2013 at 01:06:45PM +0800, Dave Young wrote:
On 10/28/13 at 01:20pm, Simon Horman wrote:
On Mon, Oct 28, 2013 at 10:30:32AM +0800, Dave Young wrote:
On 10/28/13 at 09:13am, Dave Young wrote:
@@ -447,7 +446,7 @@ void setup_subarch(struct x86_linux_para
On Mon, Oct 28, 2013 at 12:10:40PM -0400, Vivek Goyal wrote:
On Mon, Oct 28, 2013 at 10:51:19AM +, Matthew Garrett wrote:
On Mon, Oct 28, 2013 at 06:45:32PM +0800, Dave Young wrote:
On 10/28/13 at 10:39am, Matthew Garrett wrote:
On Mon, Oct 28, 2013 at 06:34:12PM +0800, Dave Young
On Sun, Oct 27, 2013 at 12:04:39PM +0800, dyo...@redhat.com wrote:
Removing code to pass acpi_rsdp because this
patch series will support efi runtime, it's not
necessary any more. EFI initialization code will
take the functionality.
I wonder if it would make more sense to make this the
last
On Mon, Oct 28, 2013 at 11:02:59AM +0800, Dave Young wrote:
On 10/28/13 at 09:12am, Dave Young wrote:
+ size = nr_maps * sizeof(struct efi_mem_descriptor) +
sizeof(struct efi_setup_data);
+ sd = malloc(sizeof(struct setup_data) + size);
+ if (!sd) {
+
On Mon, Oct 28, 2013 at 10:30:32AM +0800, Dave Young wrote:
On 10/28/13 at 09:13am, Dave Young wrote:
@@ -447,7 +446,7 @@ void setup_subarch(struct x86_linux_para
if (!debugfs_mnt)
return;
snprintf(filename, PATH_MAX, %s/%s, debugfs_mnt,
On Thu, Sep 05, 2013 at 05:21:21PM +0800, WANG Chao wrote:
People are not always aware of PACKED macro and tend to
__attribute__((packed)) more directly. So let's remove PACKED to unify
things.
Signed-off-by: WANG Chao chaow...@redhat.com
Thanks, this looks good to me.
Reviewed-by: Simon
On Wed, Oct 16, 2013 at 03:14:11PM +0800, Zhang Yanfei wrote:
Hello simon,
On 10/16/2013 03:12 PM, Simon Horman wrote:
On Thu, Sep 05, 2013 at 05:21:21PM +0800, WANG Chao wrote:
People are not always aware of PACKED macro and tend to
__attribute__((packed)) more directly. So let's remove
On Tue, Oct 15, 2013 at 07:50:57PM +0200, Geert Uytterhoeven wrote:
kexec support for Linux/m68k (tools part)
This is a set of patches to add kexec support for m68k to kexec-tools.
- Kexec only, no kdump support yet (do you have enough RAM to keep a
crashdump kernel in memory at all
On Tue, Oct 15, 2013 at 07:05:28PM +0200, Laurent Dufour wrote:
While reviewing fs2dt.c in the common kexec directory, in order to use it to
support little endian ppc64 architecture, I found some endianess
conversion's issues.
In dt_reserve, dt_base is a pointer and thus should not be
On Wed, Oct 16, 2013 at 11:33:43AM +0200, Laurent Dufour wrote:
On 16/10/2013 09:28, Simon Horman wrote:
On Tue, Oct 15, 2013 at 07:05:28PM +0200, Laurent Dufour wrote:
While reviewing fs2dt.c in the common kexec directory, in order to use it
to
support little endian ppc64 architecture
On Thu, Oct 17, 2013 at 10:42:53AM +0900, Simon Horman wrote:
On Wed, Oct 16, 2013 at 11:33:43AM +0200, Laurent Dufour wrote:
On 16/10/2013 09:28, Simon Horman wrote:
On Tue, Oct 15, 2013 at 07:05:28PM +0200, Laurent Dufour wrote:
While reviewing fs2dt.c in the common kexec directory
On Thu, Oct 03, 2013 at 08:19:34PM +, Geoff Levand wrote:
The putnode() routine in fs2dt.c was not checking for errors
returned from calls to read(). Add checks for these errors
and abort the setup of printing from purgatory if the checks
fail.
Signed-off-by: Geoff Levand
On Thu, Oct 03, 2013 at 08:19:34PM +, Geoff Levand wrote:
Add a local variable 'result' to the putnode() routine of
ds2dt and use it to hold return values of calls to read().
Fixes build warnings like these:
kexec/fs2dt.c: warning: ignoring return value of ‘read’
Thanks, applied.
On Wed, Oct 02, 2013 at 08:49:46PM +, Geoff Levand wrote:
Add a local variable and check return values.
The patch seems to do a bit more than that.
Could you either split the patch up or enhance the changelog?
Fixes build warnings like these:
kexec/fs2dt.c: warning: ignoring return
On Wed, Oct 02, 2013 at 08:54:13PM +, Geoff Levand wrote:
Hi Simon,
Here are a few generic kexec-tools fixups I have. The last one, 'Update to
automake-1.11', is in preparation for the arm64 support I am working on, but I
don't think it a bad idea to update to newer config files
On Wed, Oct 02, 2013 at 10:42:27AM +0200, Geert Uytterhoeven wrote:
When calling locate_hole() with hole_size equal to the size of an
available memory block, it fails to use that memory block.
end and hole_max point to the last byte within the range, hence
- size = end - start is one less
On Tue, Sep 24, 2013 at 10:52:54AM +0530, Athira Rajeev wrote:
From: Suzuki K. Poulose suz...@in.ibm.com
If the primary kernel doesn't use an initrd,
we may not have linux,initrd-* entries in the
device-tree, and hence the initial flat tree
may not contain them.
Make sure we add the
On Tue, Sep 24, 2013 at 10:53:10AM +0530, Athira Rajeev wrote:
From: Suzuki K. Poulose suz...@in.ibm.com
We should check if the initrd is in uImage format, when
the kernel might be in ELF.
Signed-off-by : Suzuki K Poulose suz...@in.ibm.com
Signed-off-by : Athira Rajeevatraj...@in.ibm.com
On Mon, Sep 23, 2013 at 10:18:12AM +0200, Geert Uytterhoeven wrote:
When calling locate_hole() with hole_size equal to the size of an
available memory block, it fails to use that memory block.
end and hole_max point to the last byte within the range, hence
- size = end - start is one less
On Tue, Sep 24, 2013 at 03:52:44PM +0530, Suzuki K. Poulose wrote:
On 09/24/2013 10:52 AM, Athira Rajeev wrote:
From: Suzuki K. Poulose suz...@in.ibm.com
If the primary kernel doesn't use an initrd,
we may not have linux,initrd-* entries in the
device-tree, and hence the initial flat
On Wed, Sep 25, 2013 at 08:16:41AM +0530, Suzuki K. Poulose wrote:
On 09/24/2013 10:53 AM, Athira Rajeev wrote:
From: Suzuki K. Poulose suz...@in.ibm.com
We should check if the initrd is in uImage format, when
the kernel might be in ELF.
Signed-off-by : Suzuki K Poulose
On Fri, Sep 20, 2013 at 09:15:02AM +0200, Geert Uytterhoeven wrote:
Hi Simon,
Thanks for your comments!
On Thu, Sep 19, 2013 at 11:07 PM, Simon Horman ho...@verge.net.au wrote:
Pasting two series in one was a bit confusing for me at first.
Perhaps you could consider posting two separate
On Tue, Sep 17, 2013 at 10:37:08AM +0200, Geert Uytterhoeven wrote:
E.g. all other Makefiles are handmade, but git complains when adding a
new kexec/arch/*/Makefile file.
Thanks, applied.
___
kexec mailing list
kexec@lists.infradead.org
On Thu, Sep 19, 2013 at 11:20:22AM +0200, Geert Uytterhoeven wrote:
On Tue, Sep 17, 2013 at 12:01 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
This is a preliminary set of patches to add kexec support for m68k.
- [PATCH 1/3] m68k: Add preliminary kexec support
- [PATCH 2/3]
On Tue, Sep 17, 2013 at 10:37:10AM +0200, Geert Uytterhoeven wrote:
Cris doesn't have support for crash kernels yet.
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
Thanks, applied.
___
kexec mailing list
kexec@lists.infradead.org
On Thu, Sep 19, 2013 at 11:10:19AM +0200, Geert Uytterhoeven wrote:
Presumably these had been copied from ppc.
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
Thanks, applied.
___
kexec mailing list
kexec@lists.infradead.org
On Tue, Sep 17, 2013 at 12:01:30PM +0200, Geert Uytterhoeven wrote:
This is a preliminary set of patches to add kexec support for m68k.
Great, this has been a long time coming!
- Kexec only, no kdump support yet (do you have enough RAM to keep a
crashdump kernel in memory at all times?
On Tue, Sep 17, 2013 at 10:37:09AM +0200, Geert Uytterhoeven wrote:
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
kexec/arch/cris/kexec-cris.c |4 ++--
kexec/arch/sh/include/arch/options.h |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
Thanks, applied.
On Thu, Jun 20, 2013 at 02:43:07PM -0700, Geoff Levand wrote:
Prefix local include paths with $(srcdir)/.
Fixes build errors like these when building for ARM out of the source tree:
cc1: fatal error: kexec/arch/arm/crashdump-arm.h: No such file or directory
Signed-off-by: Geoff Levand
On Wed, May 22, 2013 at 10:57:35AM +0200, Thomas Renninger wrote:
add_memmap() will add another memrange, therefore we need an additional
array entry and need to check for
if (nr_entries = CRASH_MAX_MEMMAP_NR - 1)
Same for delete_memmap: If a region has to be split an additional region is
On Wed, May 22, 2013 at 10:57:34AM +0200, Thomas Renninger wrote:
There are several places where memory range arrays are printed for debug
reasons. In load_crashdump_segments() the memory type is missing.
Unify printing memory ranges in --debug case in a macro and add the first
users.
On Sun, May 26, 2013 at 06:02:37PM +0800, Zhang Yanfei wrote:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
The return will never be reached, so remove it.
Thanks, applied.
___
kexec mailing list
kexec@lists.infradead.org
On Sat, Apr 27, 2013 at 02:35:11PM +0800, Zhang Yanfei wrote:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
The function add_backup_segments is only called by my_load and
they are in the same file. So unnecessary to export it. Make it
static.
Signed-off-by: Zhang Yanfei
On Tue, Apr 30, 2013 at 09:12:28AM +0800, Zhang Yanfei wrote:
We used 1024 as the percpu crash note size. But for new kernel that
exports the real crash note size, we should parse it instead of
using 1024.
Thanks, applied.
___
kexec mailing list
On Tue, Apr 16, 2013 at 09:04:31PM +0800, Zhang Yanfei wrote:
Hi Simon,
I found that you may apply the patch from Suzuki with a wrong commit
description by mistake. So I send this revert patch and resend the
patch in another mail with a subject:
[PATCH RESEND] kexec/powerpc: Handle
On Tue, Apr 09, 2013 at 05:27:06PM +0900, Atsushi Kumagai wrote:
Hello,
This patchset is to work with remove vm_struct list management:
https://lkml.org/lkml/2013/3/13/40
I tested this on i386/x86_64, but I can't do it on other
architectures. So, please let me know if you find any
On Sat, Apr 06, 2013 at 01:39:40PM +0800, Zhang Yanfei wrote:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
When compile kexec-tools in i386, we got the following warnings:
kexec/kexec-elf-rel.c: In function ‘elf_rel_set_symbol’:
kexec/kexec-elf-rel.c:517: warning: format ‘%ld’ expects
On Mon, Apr 08, 2013 at 09:38:49AM +0800, Zhang Yanfei wrote:
于 2013年04月08日 09:37, Simon Horman 写道:
On Sat, Apr 06, 2013 at 01:39:40PM +0800, Zhang Yanfei wrote:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
When compile kexec-tools in i386, we got the following warnings:
kexec/kexec
On Mon, Apr 08, 2013 at 10:11:09AM +0800, Zhang Yanfei wrote:
于 2013年04月08日 10:08, Simon Horman 写道:
On Mon, Apr 08, 2013 at 09:38:49AM +0800, Zhang Yanfei wrote:
于 2013年04月08日 09:37, Simon Horman 写道:
On Sat, Apr 06, 2013 at 01:39:40PM +0800, Zhang Yanfei wrote:
From: Zhang Yanfei zhangyan
On Tue, Apr 02, 2013 at 07:20:51AM +0200, Richard Weinberger wrote:
Am Tue, 02 Apr 2013 14:09:02 +0800
schrieb Zhang Yanfei zhangyan...@cn.fujitsu.com:
Yeah, this is one case.
Someone may also download a kexec-tools tarball from internet,
and then want to build a RPM. Even git isn't
On Mon, Apr 01, 2013 at 01:23:04PM +0200, Richard Weinberger wrote:
This file is nowhere referenced, let's get rid of it.
Signed-off-by: Richard Weinberger rich...@nod.at
Thanks, applied.
___
kexec mailing list
kexec@lists.infradead.org
On Thu, Mar 28, 2013 at 09:09:59PM +0800, Zhang Yanfei wrote:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
Functions:
- cmdline_add_memmap()
- cmdline_add_memmap_acpi()
- cmdline_add_memmap_reserved()
is kind of similar, So add a new function cmdline_add_memmap_internal() to
hold the
it intead of using 1024.
The idea came from Vivek Goyal. And a later patch will be sent to
kexec-tools to let it parse the size.
Acked-by: Simon Horman ho...@verge.net.au
Cc: Greg KH gre...@linuxfoundation.org
Cc: Eric W. Biederman ebied...@xmission.com
Cc: Vivek Goyal vgo
...@redhat.com
Signed-off-by: Zhang Yanfei zhangyan...@cn.fujitsu.com
Assuming that patch 1 of this series is accepted:
Acked-by: Simon Horman ho...@verge.net.au
---
Documentation/ABI/testing/sysfs-devices-system-cpu | 12
1 files changed, 12 insertions(+), 0 deletions
On Mon, Mar 25, 2013 at 11:01:49PM +0800, Zhang Yanfei wrote:
于 2013年03月25日 20:39, Cliff Wickman 写道:
On Mon, Mar 25, 2013 at 03:42:09PM +0800, Zhang Yanfei wrote:
??? 2013???03???05??? 09:51, Simon Horman ??:
On Mon, Feb 04, 2013 at 01:53:55PM -0600, Cliff Wickman wrote:
From: Cliff
On Mon, Mar 25, 2013 at 03:53:44PM +0800, Li Haifeng wrote:
When make kdump object file, the expression of linking kdump ignores
LDFLAGS. If someone want to build kdump with static links, it won't
product object file with static attributes. So, fix it.
Signed-off-by: Haifeng Li
On Mon, Mar 25, 2013 at 06:56:49PM +0800, zhouzho...@gmail.com wrote:
From: root root@zzy-Lenovo.(none)
The above line is bogus.
On Documentation/kdump/kdump.txt, section Boot into System Kernel: On x86
and x86_64, use
crashkernel=64M@16M, but some OSes like ubuntu 12.10 use ram fs
On Thu, Mar 21, 2013 at 06:00:29PM +0800, Dave Young wrote:
On 03/21/2013 05:02 PM, Baoquan wrote:
On 03/21/2013 04:56 PM, Baoquan wrote:
On 03/21/2013 04:51 PM, Simon Horman wrote:
On Thu, Mar 21, 2013 at 03:14:11PM +0800, Baoquan wrote:
Hi Simon,
After git pull, I didn't find
On Mon, Mar 25, 2013 at 11:05:49PM +0800, Zhang Yanfei wrote:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
Since get_command_line returns dynamically allocated memory, it is
easy for the caller to forget freeing the memory. Here fixes a
memory leak caused by this function.
Signed-off-by:
On Mon, Mar 25, 2013 at 11:03:52PM +0800, Zhang Yanfei wrote:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
If the if test is ok, then it will call die() to exit the process,
so freeing line will not be reached, causing memory leak. Fix this.
Thanks, applied.
On Mon, Mar 25, 2013 at 11:09:01PM +0800, Zhang Yanfei wrote:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
Since get_command_line returns dynamically allocated memory, it is
easy for the caller to forget freeing the memory. Here fixes a
memory leak caused by this function.
Signed-off-by:
On Mon, Mar 25, 2013 at 11:10:35PM +0800, Zhang Yanfei wrote:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
In multiboot_x86_load, allocated memory may not be free'd if the code
exits abnormally, by calling return. So the patch fixes the possible
memory leak.
Besides, remove some extra
On Mon, Mar 25, 2013 at 11:07:49PM +0800, Zhang Yanfei wrote:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
In elf_x86_load, allocated memory may not be free'd if the code
exits abnormally, by calling die() or return. So the patch fixes
the possible memory leak.
This patch is also a
On Mon, Mar 25, 2013 at 11:11:29PM +0800, Zhang Yanfei wrote:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
Since get_command_line returns dynamically allocated memory, it is
easy for the caller to forget freeing the memory. Here fixes a
memory leak caused by this function.
Signed-off-by:
On Mon, Mar 25, 2013 at 11:13:40PM +0800, Zhang Yanfei wrote:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
Since get_command_line returns dynamically allocated memory, it is
easy for the caller to forget freeing the memory. Here fixes a
memory leak caused by this function.
Signed-off-by:
On Mon, Mar 25, 2013 at 11:15:42PM +0800, Zhang Yanfei wrote:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
Since get_command_line returns dynamically allocated memory, it is
easy for the caller to forget freeing the memory. Here fixes a
memory leak caused by this function.
Signed-off-by:
On Mon, Mar 25, 2013 at 11:15:00PM +0800, Zhang Yanfei wrote:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
In ppc_load_bare_bits, allocated memory may not be free'd if the code
exits abnormally, by calling die() or return. So the patch fixes
the possible memory leak.
This patch is also a
On Mon, Mar 25, 2013 at 11:17:29PM +0800, Zhang Yanfei wrote:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
Since get_command_line returns dynamically allocated memory, it is
easy for the caller to forget freeing the memory. Here fixes a
memory leak caused by this function.
Signed-off-by:
On Mon, Mar 25, 2013 at 11:18:19PM +0800, Zhang Yanfei wrote:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
In elf_x86_64_load, allocated memory may not be free'd if the code
exits abnormally, by calling die() or return. So the patch fixes
the possible memory leak.
Signed-off-by: Zhang
On Mon, Mar 25, 2013 at 11:16:34PM +0800, Zhang Yanfei wrote:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
Since get_command_line returns dynamically allocated memory, it is
easy for the caller to forget freeing the memory. Here fixes a
memory leak caused by this function.
Signed-off-by:
On Mon, Mar 25, 2013 at 11:21:51PM +0800, Zhang Yanfei wrote:
于 2013年03月20日 21:21, Simon Horman 写道:
On Wed, Mar 20, 2013 at 09:17:51PM +0800, Zhang Yanfei wrote:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
Since we have the err() interface, so replace the error printing
function
On Wed, Mar 27, 2013 at 08:42:28PM +0800, Zhang Yanfei wrote:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
This reverts commit 49320340f705694e387d794f7f19d407ad9baefa. The change
of COMMAND_LINE_SIZE cannot solve Cliff's problem since the kernel side
has the restriction, so it is useless.
On Wed, Mar 27, 2013 at 10:00:59PM +0800, Zhang Yanfei wrote:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
Use die() to simplify code.
Signed-off-by: Zhang Yanfei zhangyan...@cn.fujitsu.com
Thanks, applied.
___
kexec mailing list
On Wed, Mar 27, 2013 at 10:09:16PM +0800, Zhang Yanfei wrote:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
fatal() nearly does the same thing as die() does, so this is kind of
duplicate. Remove fatal() and use die() instead.
Signed-off-by: Zhang Yanfei zhangyan...@cn.fujitsu.com
Thanks,
601 - 700 of 1232 matches
Mail list logo
