Re: kdump without the kexec

* Lei Wen [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 kernel > with kexec

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 [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 to start > a c

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 r

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

Re: [PATCH 0/3] Getting biarch support

Zitat von "Eric W. Biederman" : 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 __

[PATCH] Fix buffer overflow when writing dh->signature

c:5457:8: \ /usr/include/bits/string3.h:107:3: warning: call to \ __builtin___strcpy_chk will always overflow destination buffer Solution: Don't copy the terminating zero byte. Signed-off-by: Bernhard Walle --- makedumpfile.c |2 +- 1 files changed, 1 insertions(+), 1 deletion

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

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

Am 06.02.2010 03:45, schrieb Sujit V: > I have integrated the kdump in our linux 2.6.23 based kernel. If I do > echo c > /proc/sysrq-trigger then it boots the kdump kernel & I use > the cp /proc/vmcore /local/crash/vmcore-incomplete > > On a new x86 based hardware (32 bit PAE kernel) the "cp /pro

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 kexec@lists.infrad

Re: Linux kernel crash dumps for ARM

Am 05.01.2010 06:20, schrieb Eric W. Biederman: >> >> 3) In lkcd, netdump,diskdump, mini kernel dump and kdump/kexec tools, >> >>- which is the best choice for ARM or are there any best crash dump tool for ARM? LKCD is more or less dead (in favour of kdump) on any plattform. It doesn't work wi

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 converter

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 al

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

Simon Horman schrieb: > This aside, is everyone happy with the patch? > I'd like to merge it if possible. No objections from my side. Regards, Bernhard ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

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 sin

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 kerne

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) c

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: > >> +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, #defin

Re: vmcore file 0 size in x86_64

Ken'ichi Ohmichi schrieb: > > If compiling your user space program with tree options > (-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE), > it can access the high memory. And it's important that you load the crashkernel with % kexec ... --elf64-core-headers or at least *withou

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 k

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

[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 --- kexec/firmware_memmap.c |2 +- kexec/firmware_memmap.h |2 +- 2 files changed, 2 insertions(+), 2 del

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

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

in the VMCOREINFO, and you even can extract the System.map from the memory, no need 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

[PATCH] [PPC64] Fix memory corruption when using realloc_memory_ranges()

s() gets called from architecture independent code and that allocation is PPC64-specific here. Signed-off-by: Bernhard Walle diff --git a/kexec/arch/ppc64/kexec-ppc64.c b/kexec/arch/ppc64/kexec-ppc64.c index b0d8acd..ad8a31c 100644 Signed-off-by: Bernhard Walle --- kexec/arch/ppc64/kexec-ppc64.c |

[PATCH] [PPC64] printf() consolidation

ff-by: Bernhard Walle diff --git a/kexec/arch/ppc64/kexec-ppc64.c b/kexec/arch/ppc64/kexec-ppc64.c index ad8a31c..8d4e42b 100644 Signed-off-by: Bernhard Walle --- kexec/arch/ppc64/kexec-ppc64.c |7 +++ 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/kexec/arch/ppc64/kexec-

[PATCH] [PPC64] Fix typo in realloc_memory_ranges()

The base_memory_range should not become memory_range. We need to realloc base_memory_range to not change the contents of memory. That was a copy & paste error. Signed-off-by: Bernhard Walle --- kexec/arch/ppc64/kexec-ppc64.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-)

[PATCH] Fix missing FILE argument in fprintf()

p-x86.c:144: warning: passing argument 2 of \ 'fprintf' makes pointer from integer without a cast Signed-off-by: Bernhard Walle --- kexec/arch/i386/crashdump-x86.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/a

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.infradea

Re: [PATCH] Parse 64 bit VMCOREINFO on 32 bit userland

is > not acceptable. Agreed. I think we need to ship 64 bit makedumpfile. Bernhard -- Bernhard Walle, SUSE Linux Products GmbH, Architecture Development ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

[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 @@ * MERC

[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 c

Re: [PATCH] Parse 64 bit VMCOREINFO on 32 bit userland

* Ken'ichi Ohmichi [2008-11-28 10:16]: > > > Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]> > > > > --- > > makedumpfile.c |7 +++ > > 1 file changed, 3 insertions(+), 4 deletions(-) > > > > --- a/makedumpfile.c > > +++

Re: [PATCH] Parse 64 bit VMCOREINFO on 32 bit userland

Hi Ken'ichi, * Ken'ichi Ohmichi [2008-11-28 10:16]: > Bernhard Walle wrote: > > This bug fixes the problem that on a 32 bit userland makedumpfile (as common > > on the PPC platform) the parsing of the 64 bit VMCOREINFO fails with: > > > ># mak

[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 |7 +++ 1 file c

Re: makedumpfile-1.3.1: Support linux-2.6.27 and linux-2.6.28.

y CONFIG_SPARSEMEM_MANUAL CONFIG_SPARSEMEM_STATIC=y CONFIG_SPARSEMEM_VMEMMAP_ENABLE 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] Fix kexec x86_64 load failed bug

s against kexec tools, not kernel. > > > > > > > > Best Regards, > > > > Huang Ying > > > > > > Hi Huang, > > > > > > I think that I would prefer "char *cmdline_end = NULL;" for kexec-tools > > >

[PATCH] Fix compile warnings in get_memory_ranges()

: \ warning: passing argument 3 of ‘parse_iomem_single’ from incompatible pointer type Yes, that was my own code. :-( Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]> --- kexec/arch/i386/kexec-x86-common.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff -

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

note 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

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

* Bernhard Walle [2008-11-25 13:49]: > > On Xen, we have to use /proc/iomem to retrieve the memory area for the kexec'd > kernel, not /sys/firmware/memmap. Dom0 kernel gets a E820 map that contains > only one region: > > -18e5e000 (System RAM) I

kexec does not load

Hi Huang, your patch: commit ceb04ae1223ba5cdd40df744aa73a32b2cc7d879 Author: Huang Ying <[EMAIL PROTECTED]> Date: Wed Oct 29 11:24:25 2008 +0800 kexec jump support for kexec-tools To support memory backup/restore an option named --load-preserve-context is added to

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

note 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 |

[PATCH] Fix spell error in help output

This patch just fixes a spell error. Found by Dave Plater. Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]> --- kexec/kexec.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kexec/kexec.c b/kexec/kexec.c index 0616091..fc01458 100644 --- a/kexec/kexec.c +++ b

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 &g

Re: [PATCH] makedumpfile: Claim to support 2.6.27

* 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 patch. > I also tested makedumpfile on linux-2

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 inte

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

exported. It should 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, Archi

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

served) 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, 1

[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_SH

Re: [PATCH] [WATCHDOG] Fix kdump when using hpwdt

eating the patch ... I'll come up with an updated patch with the suggestions from Vivek. Probably tomorrow. Regards, Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

[PATCH] [WATCHDOG] Fix kdump when using hpwdt

f 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: Bern

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

t topic in the crash mailing list, sorry). Regards, Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

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

sh", but rather an issue with the data > inside 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 _

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.

[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]> --- kexe

Re: kdump: quad core Opteron

rint out the address, and then look at which address it crashes. Then look in the memory map, maybe there's something special there. Regards, Bernhard -- Bernhard Walle, SUSE Linux Products GmbH, Architecture Development ___ kexec mailing list kex

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

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) > +

[patch] [PATCH] Fix memory leaks

m 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(&q

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

/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_

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. http://article.gmane.org/gmane.linux.ports.i

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.i

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 > > c

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

* Jay Lan <[EMAIL PROTECTED]> [2008-09-09]: > > I talked to Jack Steiner about this problem. He said: > The memory at 0xe0600010 is part of Altix "fetchop" space > (AKA mspec). The memory supports only uncached attributes. A normal > "cached" access may cause MCAs. > > The kernel

[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.

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

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

Re: [PATCH][ia64] Fix the difference between node_mem_map and node_start_pfn. (Re: makedumpfile fails on SGI machine)

d > vmem_map. > > The attached patch fixes the kernel bug, and makedumpfile can work without > '-x' option. I tested it on my ia64 none-NUMA machine, and it works fine. > Could you test the attached patch on your machine again ? Thanks for the patch! This works fine on my

kdump broken on Altix 350

ue. :) 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 broken on Altix 350

* Bernhard Walle [2008-08-29 18:03]: > > 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 boo

Re: How do i see printf output from the purgatory code?

27;t use --noio (which is the default on SUSE on IA64 because we had problems on some machines without that parameter). Bernhard -- Bernhard Walle, SUSE Linux Products GmbH, Architecture Development ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

Re: makedumpfile fails on SGI machine

ile'. It now generated a dump file fine. 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 L

Re: kexec -p loads

pile the > vmlinux for a fixed physical address (Address in reserved region) and then > use it? In this case his vmlinux seems to have been compiled for physical > address 16MB. Which should be usable if there is a reserved memory region > at 16MB. Of course, that's true. I ju

Re: kexec -p loads

> > segment[1].memsz = 1000 > > > > I think above two segments are not being loaded at right place. Looks like > kexec-tools decided to load first one at physical address 0x1000 and other at > physical address 0xa000. For crash kernel this is not right. It should >

Re: Zero size vmcore on ia64

s -l /proc/vmcore > I am sorry to say, I tried to follow your instruction but finally the > out put is zero. > lfg-ia64:~ # ls -l /proc/vmcore > -r 1 root root 0 2008-08-27 18:40 /proc/vmcore Strange. Which hardware is that? Bernhard -- Bernhard

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 l

Re: Zero size vmcore on ia64

.org) on kdump and kexec issues. I 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

[PATCH] Use /usr/bin/nm -D on stripped binaries

" output) and report "unknown" if the looked address is outside of the function. Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]> 2 files changed, 55 insertions(+), 12 deletions(-) defs.h|1 symbols.c | 66 +--

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: > >

[PATCH] Update INSTALL

dy present. Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]> --- INSTALL | 83 ++ 1 files changed, 61 insertions(+), 22 deletions(-) diff --git a/INSTALL b/INSTALL index e422868..442215f 100644 --- a/INSTALL +++ b/INSTALL @@ -1,38 +1

[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/Makef

[PATCH] [PATCH] Add INSTALL file

1 file changed, 65 insertions(+) INSTALL | 65 +++ To describe static compilation. I hope the rest is also okay. Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]> diff --git a/INSTALL b/INSTALL new file mode 100644 --- /de

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 > >

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

>. Although I don't see the practical benefit in most cases, I don't think we should not support it. Since kexec does not use name resolution functions of libc, it's valid to use static linking. Tested on x86_64-suse-linux. Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>

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.or

Re: Memory needed for a kdump kernel has been bloated

* Jay Lan <[EMAIL PROTECTED]> [2008-08-21 14:00]: > > Bernhard Walle wrote: > > * Jay Lan <[EMAIL PROTECTED]> [2008-08-21 13:35]: > >> 2) the kdump kernel tried to add disk /dev/sdb when it is not even > >>in /etc/fstab. I think only the system disk

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

Re: Memory needed for a kdump kernel has been bloated

ernel? What do you mean with "add disk"? Mount? Load driver? That's up to initrd and/or system configuration ... Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development "Make everything as simple as possible, but no

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

Re: Kdump Automation Mechanism

* 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 liked “/var/log/dump” since it's not a logfile.] Bernhard -- Bernhard Walle, SUSE LIN

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. > >>

Re: Kdump Automation Mechanism

=> KDUMP_SAVEDIR in /etc/sysconfig/kdump => KDUMP_DUMPLEVEL for makedumpfile 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 no

Re: Kdump Automation Mechanism

across distributions although I consider that in general as a good idea. Bernhard [1] mkdumprd on SUSE is only a script that calls mkinitrd with right parameters while the mkdumprd on RedHat builds a initramfs for kdump itself with busybox -- Bernhard Walle, SUSE LINUX Products GmbH, Ar

Re: Kdump compressed format

* Ken'ichi Ohmichi [2008-08-11 21:03]: > Bernhard Walle wrote: > > * 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

Re: Kdump compressed format

idoc, I can also create a HTML / PDF documentation 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: makedumpfile fails on SGI machine

n > "PAGETABLE_4L : ON". See the attachment. Bernhard -- 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

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. ;-) > >

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

  1   2   3   4   5   >