Re: kdump without the kexec

* Lei Wen adrian.w...@gmail.com [2011-05-06 16:33]: Is there any existed solution that could make the kdump without the kexec? For some kind of system hang, always hardware bug, or software deadlock, which could not trigger the kernel oops, so that the first kernel cannot load the second

Re: kdump_post : busybox returns Applet not found

Am 05.12.10 21:19, schrieb Neil Horman: I'm kind of suprised this is working at all. I don't see a #!/bin/sh or #!/bin/msh line at the top of the script. How does the system know what interpreter to use? /bin/sh is the default interpreter. Regards, Bernhard

Re: [rfc] Merge kexec-tools into the kernel tree

* Simon Horman ho...@verge.net.au [2010-08-04 09:06]: Given that there have been a bunch of issues with kexec on power that this would resolve. and there is precedence for tools in the kernel tree, this sounds entirely reasonable to me. So with my kexec-tools maintainer hat on, I would like

Re: [PATCH 3/4] Revert x86: disable IOMMUs on kernel crash

Am 03.04.10 19:49, schrieb Eric W. Biederman: Not a problem. We require a lot of things of the kdump kernel, and it is immediately apparent in a basic sanity test. Also, in most cases (for example: distribution kernels), the kdump kernel nowadays is identical to the running kernel. So, if the

Re: [PATCH 6/6] kexec-tools: Use default rpmbuild definations

Am 24.03.2010 12:30, schrieb Simon Horman: On Sat, Mar 20, 2010 at 10:43:49AM +0100, Bernhard Walle wrote: Am 19.03.2010 21:37, schrieb Eric W. Biederman: Ameya Palande 2am...@gmail.com writes: Since current mechanism for building rpm into custom directory is not working, remove

Re: [PATCH 6/6] kexec-tools: Use default rpmbuild definations

Am 19.03.2010 21:37, schrieb Eric W. Biederman: Ameya Palande 2am...@gmail.com writes: Since current mechanism for building rpm into custom directory is not working, remove it and switch to system defaults for rpmbuild. Does RPM really bit rot that quickly? I know at the time I added

Re: [PATCH 0/3] Getting biarch support

Zitat von Eric W. Biederman ebied...@xmission.com: It looks like no one ever tested taking a crashdump from a 64bit kernel with a 32bit userspace on x86, and we have a reuse-cmdline regression fixes follow. I didn't even know that it is supposed to work... Regards, Bernhard

Re: kdump cp /proc/vmcore exiting with Invalid Argument Error

Am 10.02.2010 um 19:46 schrieb Sujit V: Tried readelf on the /proc/vmcore but gave the below error. The readelf worked correctly on another binary. kdump shell/sbin/readelf -l /proc/vmcore readelf: Error: Cannot stat input file /proc/vmcore. My only guess is that readelf has no large file

Re: [PATCH] Fix --reuse-cmdline so it is usable.

Am 25.01.2010 09:14, schrieb Eric W. Biederman: Where does the memory that getopt uses come from? The optarg string points to the original *argv[] array and doesn't allocate new memory. Regards, Bernhard ___ kexec mailing list

Re: Kexec not working as expected from inside X

Mayank Kaushik schrieb: Is it something in the nvidia driver that's causing this to not work? Any clues on what's going wrong, or how I can debug this further? You should attach a serial console to debug that. Is that possible on your system. It's also possible to use a USB-to-RS232

Re: [PATCH] Reserve memory for kdump kernel within RMO region

M. Mohan Kumar schrieb: Hi, As of now the kdump kernel base is fixed to be 32MB. The intention of this patch is to modify that behaviour (for relocatable kernels) * Regular kernel size may exceed 32MB, in this case we can't have kdump kernelbase as 32MB. * crashkernel=auto also

Re: [PATCH] Reserve memory for kdump kernel within RMO region

M. Mohan Kumar schrieb: On 11/26/2009 12:22 AM, Bernhard Walle wrote: M. Mohan Kumar schrieb: Reserve memory for kdump kernel within RMO region When the kernel size exceeds 32MB(observed with some distros), memory for kdump kernel can not be reserved as kdump kernel base is assumed

Re: [PATCH] kexec.c: workaround getline and fscanf to make it *libc agnostic. Tested against klibc and dietlibc.

Yuri Bushmelev schrieb: That is form of 'early bug detection' of mistyped '=='. E.g. you can write by mistype if (p = NULL) {} but can't if (NULL = p) {} because you will get compiler error. I know that kind of argument. However, it makes code IMO quite unreadable since it's

Re: [PATCH] Reserve memory for kdump kernel within RMO region

M. Mohan Kumar schrieb: Reserve memory for kdump kernel within RMO region When the kernel size exceeds 32MB(observed with some distros), memory for kdump kernel can not be reserved as kdump kernel base is assumed to be 32MB always. When the kernel has CONFIG_RELOCATABLE option enabled,

Re: [PATCH] kexec.c: workaround getline and fscanf to make it *libc agnostic. Tested against klibc and dietlibc.

Simon Horman schrieb: + + if ( NULL == p) + return -1; Wouldn't that be better 'p == NULL'? + ret = strtol(line, p, 10); + + /* Too long */ + if (ret INT_MAX) + return -1; An integer that can be represented in 2 (strlen(__\0)==3) cannot be

Re: [PATCH] kexec.c: workaround getline and fscanf to make it *libc agnostic. Tested against klibc and dietlibc.

Simon Horman schrieb: +char *line = malloc(sizeof_line); /* according to strdup() later */ Could line be char line[1024] ? Better would be a constant. However, 1024 is too less since the maximum command line size can be 2048 currently on x86 (arch/x86/include/asm/setup.h, #define

Re: [Patch 0/7] Implement crashkernel=auto

Andi Kleen schrieb: As an initial approximation I would use a 32nd of low memory. That means a 1TB machine will have a 32GB crash kernel. Surely that's excessive?!? It would be repeating all the same mistakes people made with hash tables several years ago. The idea of Eric was to

Re: [Patch 0/7] Implement crashkernel=auto

Eric W. Biederman schrieb: With the current set of crashkernel= options we are asking the distribution installer to perform magic. Moving as much of this logic into a normal init script for better maintenance is desirable. Not (necessarily) the installer but the program that configures

[PATCH] Correct email addresses

Since I don't work for SUSE any more and 'bwa...@suse.de' is invalid, correct it in the copyright so that people can still contact me. Signed-off-by: Bernhard Walle bernhard.wa...@gmx.de --- kexec/firmware_memmap.c |2 +- kexec/firmware_memmap.h |2 +- 2 files changed, 2 insertions

Re: [PATCH] powerpc: initialize drconf variables

* Chandru [2009-02-04 17:16:28]: + strcpy(fname, /proc/device-tree/); + strcat(fname, ibm,dynamic-reconfiguration-memory/ibm,lmb-size); + if ((file = fopen(fname, r)) == NULL) { + perror(fname); + return -1; + } + if (fread(buf, 1, 8, file) 0) {

Re: [PATCH]: add dmesg log symbols to /proc/vmcoreinfo lists

to have System.map files copied. Yes, that's the same amount of addition in the initrd, but it opens more possibilities than just the log buffer. Bernhard -- Bernhard Walle, SUSE Linux Products GmbH, Architecture Development ___ kexec mailing

Release?

Hi, wouldn't it time for kexec-tools 2.1? There are many changes in git currently. :) Bernhard -- Bernhard Walle, SUSE Linux Products GmbH, Architecture Development ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org

[patch] [PATCH] Parse 64 bit VMCOREINFO on 32 bit userland

)=c0bb4400 We just need to assume that the symbols are always 'unsigned long long' (64 bit) instead of 'unsigned long' (native pointer size on Linux platforms). Signed-off-by: Bernhard Walle [EMAIL PROTECTED] --- makedumpfile.c |8 1 file changed, 4 insertions(+), 4

[patch] Remove stdlib.h

This patch just removes stdlib.h reference in makedumpfile.c. It's already included in makedumpfile.h. Signed-off-by: Bernhard Walle [EMAIL PROTECTED] --- makedumpfile.c |1 - 1 file changed, 1 deletion(-) --- a/makedumpfile.c +++ b/makedumpfile.c @@ -13,7 +13,6 @@ * MERCHANTABILITY

[PATCH] Don't use /sys/firmware/memmap for Xen

1f0b4b80-1f0b4d13 : Crash note 1f0b4e00-1f0b4f93 : Crash note ... Without that patch, /proc/vmcore is empty in the kexec'd kernel and I'm unable to copy the crashdump. Signed-off-by: Bernhard Walle [EMAIL PROTECTED] --- kexec/arch/i386/kexec-x86-common.c | 10 +- 1 files

Re: [PATCH] Fix kexec x86_64 load failed bug

-tools code too. Patch v2 follows with NULL instead of 0. Thanks, applied. Verified. Huang, thanks for the quick fix! Bernhard -- Bernhard Walle, SUSE Linux Products GmbH, Architecture Development ___ kexec mailing list kexec

[PATCH] Don't use /sys/firmware/memmap for Xen

1f0b4b80-1f0b4d13 : Crash note 1f0b4e00-1f0b4f93 : Crash note ... Without that patch, /proc/vmcore is empty in the kexec'd kernel and I'm unable to copy the crashdump. Signed-off-by: Bernhard Walle [EMAIL PROTECTED] --- kexec/arch/i386/kexec-x86-common.c |9 - 1 files

Re: [PATCH] makedumpfile: Claim to support 2.6.27

Hi Ken'ichi, * Ken'ichi Ohmichi [2008-11-14 11:09]: Bernhard Walle wrote: * Ken'ichi Ohmichi [2008-11-13 18:07]: Bernhard Walle wrote: According to the changelog and my tests, 2.6.27 kernel is supported. Express that in the LATEST_VERSION check. Thank your for your tests and your

Re: [PATCH] Always use 64 bit addresses for the firmware memory map

* H. Peter Anvin [2008-11-12 15:35]: Bernhard Walle wrote: * H. Peter Anvin [2008-11-12 11:59]: I want to make sure, though, that we don't just end up pushing the truncation further down in the code. Well, I think that interface should export the BIOS memmap as provided. Since E820

[PATCH] makedumpfile: Claim to support 2.6.27

According to the changelog and my tests, 2.6.27 kernel is supported. Express that in the LATEST_VERSION check. Signed-off-by: Bernhard Walle [EMAIL PROTECTED] diff --git a/makedumpfile.h b/makedumpfile.h --- a/makedumpfile.h +++ b/makedumpfile.h @@ -436,7 +436,7 @@ #define KVER_MIN_SHIFT 16

[PATCH] Always use 64 bit addresses for the firmware memory map

) fec0-fec01000 (reserved) Just always using 64 bit is the most sane approach in my opinion. Signed-off-by: Bernhard Walle [EMAIL PROTECTED] --- drivers/firmware/memmap.c| 17 +++-- include/linux/firmware-map.h | 12 +--- 2 files changed, 12 insertions

Re: [PATCH] Always use 64 bit addresses for the firmware memory map

even possible to kexec a PAE kernel from a non PAE kernel ... I didn't test, but it could work. But only if the E820 map is correctly written in the zero page, which is only the case if we get it correctly. Regards, Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

[PATCH] [WATCHDOG] Fix kdump when using hpwdt

of that, it must be executed as last notifier, which currently is done. So, that patch returns NOTIFY_OK in case allow_kdump is set as module parameter in the hpwdt module. Also, it changes the default of allow_kdump to 1. Kdump is quite common and should be working as default. Signed-off-by: Bernhard Walle

Re: kexec/kdump produces incomplete dump files with kernel 2.6.20 + CONFIG_HIGHMEM64G

the dump file (specifically the vmalloc'ed memory). Do you use the same kernel as the running kernel as capture kernel? Regards, Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development ___ kexec mailing list kexec@lists.infradead.org

Re: kexec on x86_64: entry32_regs not found cannot get

* Dan Upton [EMAIL PROTECTED] [2008-10-16 13:47]: I'm trying to use kexec to help debug some scheduler work I'm doing, but I can't seem to get kexec to load the kernel. I'm using kexec-tols-testing-20080227. Why don't you try 2.0.0 first? Regards, Bernhard -- Bernhard Walle, SUSE LINUX

[PATCH] Use return value of count_dyn_reconf_memory_ranges()

This patch fixes the build error kexec/arch/ppc64/kexec-ppc64.c:140: \ warning: control reaches end of non-void function The patch returns 0 on success, and checks when the function is called for a non-zero value. Signed-off-by: Bernhard Walle [EMAIL PROTECTED] --- kexec/arch

Re: [PATCH]IA64: assign a distinguishable label to uncached memory in /proc/iomem

* Jay Lan [EMAIL PROTECTED] [2008-09-11]: - } else { - name = System RAM; - } + } else if (md-attribute == EFI_MEMORY_UC) +

Re: [PATCH]IA64: assign a distinguishable label to uncached memory in /proc/iomem

* Bernhard Walle [EMAIL PROTECTED] [2008-09-12]: Isn't that too much indent, i.e. shouldn't that be Of course --- a/arch/ia64/kernel/efi.c +++ b/arch/ia64/kernel/efi.c @@ -1232,9 +1232,10 @@ efi_initialize_iomem_resources(struct re if (md-attribute

Re: the exiting makedumpfile is almost there... :)

* Ken'ichi Ohmichi [EMAIL PROTECTED] [2008-09-11]: I have not tested makedumpfile on IA64 linux-2.6.27-rcX yet, because IA64 linux-2.6.27-rcX kernel gets a panic while booting. So I guess that there is some thing wrong in my .config file.

[patch] [PATCH] Don't write undefined values to disk

) (in /lib64/libc-2.8.so) ==24152== Address 0x7fefffbfc is on thread 1's stack Signed-off-by: Bernhard Walle [EMAIL PROTECTED] --- makedumpfile.c |1 + 1 file changed, 1 insertion(+) --- a/makedumpfile.c +++ b/makedumpfile.c @@ -4707,6 +4707,7 @@ write_kdump_header(void

[patch] [PATCH] Fix memory leaks

for real memory leaks with valgrind. Signed-off-by: Bernhard Walle [EMAIL PROTECTED] --- makedumpfile.c | 12 1 file changed, 12 insertions(+) --- a/makedumpfile.c +++ b/makedumpfile.c @@ -5268,6 +5268,14 @@ close_dump_bitmap(void) ERRMSG(Can't close the bitmap file

Re: kdump broken on Altix 350

* Luck, Tony [EMAIL PROTECTED] [2008-08-29]: your commit commit 10617bbe84628eb18ab5f723d3ba35005adde143 Author: Tony Luck [EMAIL PROTECTED] Date: Tue Aug 12 10:34:20 2008 -0700 [IA64] Ensure cpu0 can access per-cpu variables in early boot code broke kdump

Re: kdump broken on Altix 350

* Bernhard Walle [EMAIL PROTECTED] [2008-08-29]: broke kdump on our Altix 350. I get following early crash in kdump kernel: Just as side note: I still have the problem with 2.6.27-rc6. Bernhard ___ kexec mailing list kexec@lists.infradead.org

Re: IA64: copying /proc/vmcore caused kernel MCA'ed

* Jay Lan [EMAIL PROTECTED] [2008-09-08]: Any input helping me speed up debugging is appreciated. I would start with comparing the ELF program headers of /proc/vmcore which you get with readelf -l /proc/vmcore in kdump environment and the /proc/iomem which kexec uses to set up the ELF core

[PATCH] Use gzip for manpage compression

Use gzip instead of zip for manual page compression. That's the usual method of compressing manual pages on Unix. Signed-off-by: Bernhard Walle [EMAIL PROTECTED] 1 file changed, 1 insertion(+), 1 deletion(-) Makefile |2 +- Use gzip instead of zip for manual page compression. That's

RE: kdump broken on Altix 350

Am Fr 29 Aug 2008 22:42:40 CEST schrieb Luck, Tony [EMAIL PROTECTED]: your commit commit 10617bbe84628eb18ab5f723d3ba35005adde143 Author: Tony Luck [EMAIL PROTECTED] Date: Tue Aug 12 10:34:20 2008 -0700 [IA64] Ensure cpu0 can access per-cpu variables in early boot code

Re: makedumpfile fails on SGI machine

. thanks for the patch, I can also report that with the patch and with vmlinux it works now. However, shouldn't we add that vmem_map to VMCOREINFO of the kernel? Thanks also Jay for testing! Bernhard -- Bernhard Walle, SUSE Linux Products GmbH, Architecture Development

Re: Zero size vmcore on ia64

Cc'd it now. Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

Re: Zero size vmcore on ia64

* jidong xiao [2008-08-27 17:51]: On Wed, Aug 27, 2008 at 5:27 PM, Bernhard Walle [EMAIL PROTECTED] wrote: Hi Jidong, * jidong xiao [2008-08-27 17:01]: I encountered the zero-size-vmcore issue on IA64. I remember last year Nanhai submitted a patch which was intended to fix this issue

Re: kexec -p loads

the error. Relocatability in ELF image never worked on x86_64 because of GDB but (so the binary was marked as ET_EXEC instead of ET_DYN). You have to use bzImage for kdump in any case. Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

Re: kexec -p loads

the numbers. Bernhard -- Bernhard Walle, SUSE Linux Products GmbH, Architecture Development ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] [PATCH] Move $(LIBS) on the end

* Yinghai Lu [2008-08-26 01:21]: On Tue, Aug 26, 2008 at 1:16 AM, Bernhard Walle [EMAIL PROTECTED] wrote: 1 file changed, 1 insertion(+), 2 deletions(-) kexec/Makefile |3 +-- To make static compilation work with LDFLAGS=-static ./configure make thanks. can you put

[PATCH] Add INSTALL to tarball

This patch just adds the installation file to the tarball. Signed-off-by: Bernhard Walle [EMAIL PROTECTED] --- Makefile.in |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile.in b/Makefile.in index 341e170..f0621e1 100644 --- a/Makefile.in +++ b/Makefile.in

Re: [PATCH] [PATCH] Move $(LIBS) on the end

* Yinghai Lu [2008-08-26 01:40]: On Tue, Aug 26, 2008 at 1:34 AM, Bernhard Walle [EMAIL PROTECTED] wrote: * Yinghai Lu [2008-08-26 01:21]: On Tue, Aug 26, 2008 at 1:16 AM, Bernhard Walle [EMAIL PROTECTED] wrote: 1 file changed, 1 insertion(+), 2 deletions(-) kexec/Makefile |3

Re: HPET regression in 2.6.26 versus 2.6.25 -- found another user with the same regression

* Yinghai Lu [2008-08-23 10:31]: add kexec guys Please add kexec@lists.infradead.org in such case. Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development ___ kexec mailing list kexec@lists.infradead.org http

Re: Memory needed for a kdump kernel has been bloated

* Jay Lan [EMAIL PROTECTED] [2008-08-21 13:35]: 1) the memory needed has been bloated since 2.6.23. and Ah, and maybe you could Cc linux-ia64 here. Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development Make everything as simple as possible, but not simpler

Re: Kdump Automation Mechanism

* Cai Qian [EMAIL PROTECTED] [2008-08-20 09:22]: --- Bernhard Walle [EMAIL PROTECTED] wrote: * Jay Lan [2008-08-14 10:23]: If you can put vmcore at the same location... Ahh, asking too much? ;) Will change that to /var/crash since that's FHS 2.3 anyway. :) [And I personally never

Re: makedumpfile fails on SGI machine

Hi, * Ken'ichi Ohmichi [2008-08-18 16:19]: Bernhard Walle wrote: * Ken'ichi Ohmichi [2008-08-05 21:07]: BTW, I'd like to know some conditions of this problem. So please let me know the makedumpfile commandline which you run. Ex. # makedumpfile -d 31 -x vmlinux /proc/vmcore dumpfile

Re: Kdump Automation Mechanism

in /etc/sysconfig/kdump = KDUMP_DUMPFORMAT (“compressed” / “ELF” / “”) in /etc/sysconfig/kdump - trigger kdump = echo c /proc/sysrq-trigger Most other stuff is “nice to have” but not “mandatory” I think? Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

Re: Kdump compressed format

from it later when I'm finished with other file formats. Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump compressed format

* Ken'ichi Ohmichi [2008-08-05 15:21]: Bernhard Walle wrote: is there any documentation how the kdump compressed format (or the diskdump format, from what it is derived) looks like? Beside of the source code of the tools that support it. ;-) The kdump compressed format is supported

Re: makedumpfile fails on SGI machine

-- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development log Description: Binary data ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

Kdump compressed format

Hi, is there any documentation how the kdump compressed format (or the diskdump format, from what it is derived) looks like? Beside of the source code of the tools that support it. ;-) Thanks for any help! Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

Re: makedumpfile fails on SGI machine

* Ken'ichi Ohmichi [2008-07-31 10:46]: Bernhard Walle wrote: After debugging that, I didn't find an error code. That address is in fact the beginning of the mem_map of that node, and is in fact not mapped (I verified that in crash). With an older kernel and an older makedumpfile

Re: makedumpfile fails on SGI machine

* Ken'ichi Ohmichi [2008-07-31 20:36]: Thank you for config file. I'm starting the kernel compiling. I'll investigate this problem the next week. Thanks in advance. Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

Fixes for firmware/memmap

This patch series fixes coding style and also moves initialisation of kobject to a safe point of time. Signed-off-by: Bernhard Walle [EMAIL PROTECTED] ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 2/2] firmware/memmap: Move kobject initialisation before kobject_add()

/0x11 [c072b67a] ? start_kernel+0x5b/0x2d1 [c072b080] ? __init_begin+0x80/0x88 === Signed-off-by: Bernhard Walle [EMAIL PROTECTED] --- drivers/firmware/memmap.c |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/drivers/firmware

Re: [PATCH 2/2] firmware/memmap: Move kobject initialisation before kobject_add()

backward step. It's _good_ that kobject_init() can be called this early. Let us strive to retain that robustness. Ok, since you have more experience with kobject, I'm fine with not applying that one. [I saw you merged the first (coding style) patch.] Bernhard -- Bernhard Walle, SUSE LINUX Products

Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

has that interface enabled by default). Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

-- because kexec needs to know the *available* memory even if that memory is disabled via 'memmap' or 'mem' command line parameters. Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development ___ kexec mailing list kexec

Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

* Bernhard Walle [EMAIL PROTECTED] [2008-07-20 15:03]: Because I didn't know that interface. And because I don't see that interface on my two systems that I just checked. i386 and x86-64. What do I have to do to enable that interface? That interface depends on CONFIG_MEMORY_HOTPLUG

[PATCH] x86: Move dma32_reserve_bootmem() after reserve_crashkernel()

in 2.6.27 because we have the automatic, dynamic offset detection, it makes sense to also include it here because: - it's easier to get it in -stable then, - many people are still used to the '[EMAIL PROTECTED]' syntax, - not everybody may be using a reloatable kernel. Signed-off-by: Bernhard

kdump: Report actual value of VMCOREINFO_OSRELEASE in VMCOREINFO

the 'makedumpfile -g' does. Signed-off-by: Bernhard Walle [EMAIL PROTECTED] diff --git a/include/linux/kexec.h b/include/linux/kexec.h index 3265968..3c7784d 100644 --- a/include/linux/kexec.h +++ b/include/linux/kexec.h @@ -127,8 +127,8 @@ void vmcoreinfo_append_str(const char *fmt

[PATCH] x86: Move crashkernel reservation before dma32_reserve_bootmem()

because we have the automatic, dynamic offset detection, it makes sense to also include it here because: - it's easier to get it in -stable then, - many people are still used to the '[EMAIL PROTECTED]' syntax, - not everybody may be using a reloatable kernel. Signed-off-by: Bernhard Walle [EMAIL

Re: problems in kdump kernel if 'maxcpus=1' not specified?

* Vivek Goyal [2008-07-16 11:12]: You need to dive deeper to find out what is taking so much of time. I think the main difference are the huge memory gaps usual on IA64 systems. makedumpfile processes each PFN sequentially when creating the 1st bitmap. Bernhard -- Bernhard Walle, SUSE LINUX

Re: problems in kdump kernel if 'maxcpus=1' not specified?

* Vivek Goyal [2008-07-16 12:34]: On Wed, Jul 16, 2008 at 05:26:01PM +0200, Bernhard Walle wrote: * Vivek Goyal [2008-07-16 11:12]: You need to dive deeper to find out what is taking so much of time. I think the main difference are the huge memory gaps usual on IA64 systems

Re: [PATCH] Use CFLAGS for compiling bin2hex

* Simon Horman [2008-07-15 20:28]: On Tue, Jul 15, 2008 at 10:48:03AM +0200, Bernhard Walle wrote: * Jeremy Kerr [2008-07-15 11:41]: $(BIN_TO_HEX): CC=$(BUILD_CC) -$(BIN_TO_HEX): CFLAGS=$(BUILD_CFLAGS) +$(BIN_TO_HEX): CFLAGS+=$(BUILD_CFLAGS) $(BIN_TO_HEX): LDFLAGS

Re: [PATCH] Allow BUILD_CFLAGS and TARGET_CFLAGS to be specified at configure time

that. :) Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] x86: Move crashkernel reservation before dma32_reserve_bootmem()

* Vivek Goyal [2008-07-14 09:30]: On Sun, Jul 13, 2008 at 08:49:44PM +0200, Bernhard Walle wrote: From: Bernhard Walle [EMAIL PROTECTED] On a x86-64 machine (nothing special I could encounter) I had the problem that crashkernel reservation with the usual [EMAIL PROTECTED] failed

[PATCH] Use CFLAGS for compiling bin2hex

This is a minor correction in the Makefile to use the CFLAGS (from configure) also for bin2hex. Signed-off-by: Bernhard Walle [EMAIL PROTECTED] --- util/Makefile |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/util/Makefile b/util/Makefile index 11d82fd..a1a78ac

Re: [ANNOUNCE] kexec-tools 2.0.0-rc1

is quite good here. I updated openSUSE Factory, that gives us a bit testing. :) Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] x86: Find offset for crashkernel reservation automatically

into kexec itself, not into the kernel. Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 1/2] firmware/memmap: Cleanup

-by: Bernhard Walle [EMAIL PROTECTED] Signed-off-by: Bernhard Walle [EMAIL PROTECTED] --- drivers/firmware/memmap.c| 61 ++--- include/linux/firmware-map.h | 26 2 files changed, 43 insertions(+), 44 deletions(-) create mode 100644

firmware/memmap fixes

are against linux-next tree and were tested on i386. Signed-off-by: Bernhard Walle [EMAIL PROTECTED] ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 2/2] firmware/memmap: Move kobject initialisation before kobject_add()

/0x11 [c072b67a] ? start_kernel+0x5b/0x2d1 [c072b080] ? __init_begin+0x80/0x88 === Signed-off-by: Bernhard Walle [EMAIL PROTECTED] Signed-off-by: Bernhard Walle [EMAIL PROTECTED] --- drivers/firmware/memmap.c |8 +++- 1 files changed, 7 insertions(+), 1

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

. Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

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

* Ken'ichi Ohmichi [2008-07-10 17:59]: Bernhard Walle wrote: * Ken'ichi Ohmichi [2008-07-10 10:16]: + if (SIZE(nodemask_t) == NOT_FOUND_LONG_VALUE) { + ERRMSG(SIZE(nodemask_t) undefined.\n); I like the following message of the same form as another message. ERRMSG(Can't get

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

* Ken'ichi Ohmichi [2008-07-10 18:20]: Bernhard Walle wrote: * Ken'ichi Ohmichi [2008-07-10 17:59]: Bernhard Walle wrote: * Ken'ichi Ohmichi [2008-07-10 10:16]: + if (SIZE(nodemask_t) == NOT_FOUND_LONG_VALUE) { + ERRMSG(SIZE(nodemask_t) undefined.\n); I like

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

use that memory map for building the ELF core headers, that was the intention for that new interface. Signed-off-by: Bernhard Walle [EMAIL PROTECTED] --- kexec/Makefile |1 + kexec/arch/i386/kexec-x86.c | 124 +++- kexec/firmware_memmap.c | 278

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

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

-by: Bernhard Walle [EMAIL PROTECTED] --- makedumpfile.c |5 + 1 file changed, 5 insertions(+) diff -u -r1.7.2.37 makedumpfile.c --- makedumpfile.c 9 Jul 2008 00:22:09 - 1.7.2.37 +++ makedumpfile.c 9 Jul 2008 11:39:43 - @@ -2580,6 +2580,11 @@ (SYMBOL

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

, I would suggest to also use the patch below: Signed-off-by: Bernhard Walle [EMAIL PROTECTED] Index: makedumpfile.c === RCS file: /cvsroot/makedumpfile/makedumpfile/makedumpfile.c,v retrieving revision 1.7.2.36 diff -u -r1.7.2.36

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

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 [EMAIL PROTECTED] --- kexec/arch/i386/Makefile |1 + kexec/arch/i386/kexec-x86-common.c | 207

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

internally. Signed-off-by: Bernhard Walle [EMAIL PROTECTED] --- kexec/arch/i386/kexec-x86.c | 96 --- kexec/firmware_memmap.c |7 +++ 2 files changed, 43 insertions(+), 60 deletions(-) diff --git a/kexec/arch/i386/kexec-x86.c b/kexec/arch/i386/kexec-x86

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

From: Bernhard Walle [EMAIL PROTECTED] 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

Parse /sys/firmware/memmap

My patch series again (without the already applied patches). Diff to last change: Define ULLONG_MAX if not already defined. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

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

-- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

Use /sys/firmware/memmap in kexec

Now as /sys/firmware/memmap is mainline in git, we can use it for kexec. Please review and give feedback. Signed-off-by: Bernhard Walle [EMAIL PROTECTED] ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo

Use /sys/firmware/memmap in kexec

Now as /sys/firmware/memmap is mainline in git, we can use it for kexec. Please review and give feedback. Signed-off-by: Bernhard Walle [EMAIL PROTECTED] ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo

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

From: Bernhard Walle [EMAIL PROTECTED] 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

  1   2   3   >