Re: [Crash-utility] Re: [PATCH 0/2] vmcoreinfo support for dump filtering #2

Vivek Goyal wrote: On Mon, Sep 10, 2007 at 11:35:21AM -0700, Randy Dunlap wrote: On Fri, 7 Sep 2007 17:57:46 +0900 Ken'ichi Ohmichi wrote: Hi, I released a new makedumpfile (version 1.2.0) with vmcoreinfo support. I updated the patches for linux and kexec-tools. PATCH SET: [1/2]

Re: [Crash-utility] Re: [PATCH 0/2] vmcoreinfo support for dump filtering #2

Randy Dunlap wrote: I have the vmcoreinfo patch applied. Kernel is 2.6.23-rc3. The crash debug output is below. Please let me know if you'd like me to test without the vmcoreinfo patch or anything else. --- crash 4.0-4.6 Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007 Red Hat,

Re: [Crash-utility] Re: handle x86_64 xen code/data relocation

Simon Horman wrote: On Tue, Apr 22, 2008 at 05:32:03PM +0900, Itsuro ODA wrote: Hi all, Recent version of xen (ex. RHEL5.2, 3.2.0) on the x86_64 moves the physical(machine) address of xen code/data area after the system started up. The start address of this is stored in 'xen_phys_start'.

Re: how to cross compile kexec for 64b x86_64 on a 32b x86

It seems that I now need the crash utility also to be cross compiled. I dont see any cross-compile support in the crash-4.0-6.3 pkg. You got that right... Any suggestions for how to cross compile the crash-4.0-6.3 for x86_64 on an x86 system. Like Bernhard suggested, try tinkering with the

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

Jay Lan wrote: After getting around a few kdump kernel panic/hang, i finally was able to complete a kdump vmcore with 2.6.27-rc5. The system under testing was an IA64 with 128 cpu and 256G memory A4700 system. The /proc/vmcore is: a4700rac:/boot # ll /proc/vmcore -r 1 root root

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

Jay Lan wrote: Jay Lan wrote: Ken'ichi Ohmichi wrote: Hi Hedi, Jay, Hedi Berriche wrote: In addition to what other folks have mentioned about giving the latest crash version a try, I'd like to point out that makedumpfile did spit a couple of warnings while creating the vmcore | Can't

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

Jay Lan wrote: Ken'ichi Ohmichi wrote: Hi Jay, Hi Ken'ichi, My IA64 linux-2.6.27-rc7 kernel could boot by your patches and its kdump succeeded, thanks. But I cannot reproduce this problem unfortunately. Could you send me your kernel .config file to reproduce it ? I just emailed

Re: [Crash-utility] cannot access vmalloc'd module memory when loading kdump'ed vmcore in crash

NOTE: I've restored the kexec list to this discussion because this 1G/3G issue does have ramifications w/respect to kexec-tools. I'm first going to ramble on about crash utility debugging for a bit here, but for the kexec/kdump masters in the audience, please at least take a look at the end of

Re: [Crash-utility] cannot access vmalloc'd module memory when loading kdump'ed vmcore in crash

- Kevin Worth [EMAIL PROTECTED] wrote: OK, let's skip the user-space angle for now, because I keep forgetting that you are running with /dev/mem as the memory source. And there is an inconsistency with your debug output that I cannot explain. As I mentioned before, the /dev/mem driver has

Re: [Crash-utility] cannot access vmalloc'd module memory when loading kdump'ed vmcore in crash

- Kevin Worth [EMAIL PROTECTED] wrote: Dave, That does seem pretty strange that the physical address is coming out beyond the 4GB mark and that the read actually succeeds. Just checked on the Ubuntu patches to the 2.6.20 kernel (

Re: makedumpfile question / request

- Ken'ichi Ohmichi oomi...@mxs.nes.nec.co.jp wrote: Hi Dave, Dave Anderson wrote: Is there a reason that makedumpfile does not fill in the utsname structure in the compressed dumpfile's header? Thank you for good point. makedumpfile does not fill it because makedumpfile might

Fwd: vmcore file size 0 on x86_64

Forwarding to kexec list. http://lists.infradead.org/mailman/listinfo/kexec - Forwarded Message - From: Chandan12 K chandan1...@tcs.com To: crash-util...@redhat.com Sent: Wednesday, August 12, 2009 2:08:54 AM GMT -05:00 US/Canada Eastern Subject: [Crash-utility] vmcore file size 0 on

Re: Can't exclude unnecessary pages for 2.6.31 Kernel

- Dave Anderson ander...@redhat.com wrote: - CAI Qian caiq...@redhat.com wrote: From: CAI Qian caiq...@redhat.com Subject: Re: Can't exclude unnecessary pages for 2.6.31 Kernel Date: Fri, 02 Oct 2009 19:26:44 +0800 (CST) Cced the crash utility maintainer. BZ filed

Re: FYI: x86_64 bug when using gdb with vmcore

- Simon Horman ho...@verge.net.au wrote: On Fri, Feb 05, 2010 at 11:53:18AM -0500, Dave Anderson wrote: The kexec/arch/x86_64/crashdump-x86_64.h file contains a stale PAGE_OFFSET value. In 2.6.27 it was changed from 0x8100UL to 0x8800UL. This is only

Re: [crash][patch] handle !SPARSEMEM_EX properly

- Daisuke Nishimura nishim...@mxp.nes.nec.co.jp wrote: In !SPARSEMEM_EX case, the symbol mem_section points a array of struct mem_section, doesn't point a array of pointer to mem_section[], so I think the check: if ((mem_sec[SECTION_NR_TO_ROOT(nr)] == 0) ||

Re: [PATCH 1/2] kexec: add phys_offset field

- Mika Westerberg ext-mika.1.westerb...@nokia.com wrote: I'm not subscribed to the list so please CC me. I had to dig this message from the archives. On Mon, Apr 26, 2010 at 02:32:21PM -0400, Dave Anderson wrote: - kexec-request at lists.infradead.org wrote: Message

Re: [PATCH 0/4] crash utility: add ARM crashdump support

- Mika Westerberg ext-mika.1.westerb...@nokia.com wrote: Hello Dave, First of all, thanks for the great tool! It is the best post-mortem analysis tool I've ever used. This series implements ARM support for the crash utility. Current implementation provides following: o

Re: [PATCH 0/4] crash utility: add ARM crashdump support

- Mika Westerberg ext-mika.1.westerb...@nokia.com wrote: On Wed, Jun 30, 2010 at 03:10:58PM +0200, ext Dave Anderson wrote: In any case, I'm more than happy to fold in ARM support, but I don't know what to do in this case. I wonder if it would it be possible for you, Jan

Re: [PATCH v2 0/6] crash utility - add ARM support

- Mika Westerberg ext-mika.1.westerb...@nokia.com wrote: Hi Dave, This series brings ARM support for the crash utility. This is the result of collaboration work with Nokia and SonyEricsson. Basically we combined our versions of the code. Previous version of the patches can be found

Re: [PATCH v1 0/6] makedumpfile: makedumpfile enhancement to filter out kernel data from vmcore

- Original Message - Hi All, Please find the makedumpfile enhancement patchset that introduces a data filtering feature which enables makedumpfile to filter out desired kernel symbol data and it's members from the specified VMCORE file. The data to be filtered out is poisoned with

Re: [PATCH v2 0/8] makedumpfile: makedumpfile enhancement to filter out kernel data from vmcore

- Original Message - On Wed, May 18, 2011 at 01:29:06AM +0530, Mahesh J Salgaonkar wrote: Hi All, Please find the version 2 of makedumpfile enhancement patchset that introduces a data filtering feature which enables makedumpfile to filter out desired kernel symbol data

Re: [PATCH v2 0/8] makedumpfile: makedumpfile enhancement to filter out kernel data from vmcore

- Original Message - The data to be erased is poisoned with character 'X' (58 in Hex). The last two patches 7/8 and 8/8 introduces eraseinfo section into filtered compressed kdump and ELF kdump file. The compressed kdump file now carries additional fields namely

Re: [RFC Patch 4/6] PANIC_MCE: Introduce a new panic flag for fatal MCE, capture related information

- Original Message - On Fri, May 27, 2011 at 11:04:06AM -0700, Eric W. Biederman wrote: K.Prasad pra...@linux.vnet.ibm.com writes: PANIC_MCE: Introduce a new panic flag for fatal MCE, capture related information Fatal machine check exceptions (caused due to hardware

Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format

- Original Message - Fujitsu has stand-alone dump mechanism based on firmware level functionality, which we call SADUMP, in short. We've maintained utility tools internally but now we're thinking that the best is crash utility and makedumpfile supports the sadump format for the

Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format

- Original Message - Now I am confused... You stated this earlier: What I meant when I used ``similar'' is both literally and logically. The format consists of diskdump header-like header, two kinds of bitmaps used for the same purpose as those in diskump format, and memory data.

Re: makedumpfile: Add erased information in compressed kdump file and ELF formatted dumpfile

Hi Mahesh, Now that this feature is in makedumpfile-1.4.0, I presume that you have crash utility warning patches underway? Also, can you confirm that compressed or kdumps with (or without) eraseinfo data can still be handled with no problem by the current version of the crash utility? I'm not

Re: [Patch 1/4][kernel][slimdump] Add new elf-note of type NT_NOCOREDUMP to capture slimdump

- Original Message - On Wed, Oct 05, 2011 at 07:20:37PM +0200, Borislav Petkov wrote: On Wed, Oct 05, 2011 at 01:10:07PM -0400, Vivek Goyal wrote: On Wed, Oct 05, 2011 at 08:58:53AM -0700, Luck, Tony wrote: The plan is to pass-down the list of poisoned memory pages to

Re: [Crash-utility] [RFC] makedumpfile, crash: LZO compression support

- Original Message - Hello Hatayama-san, Thank you for your work. Performance Comparison: Sample Data Ideally, I must have measured the performance for many enough vmcores generated from machines that was actually running, but now I

Re: [Crash-utility] [RFC] makedumpfile, crash: LZO compression support

- Original Message - Hello Kumagai-san, Thanks for the evaluation. So I'll re-post the patch soon removing RFC prefix in header. But there is a remaining fix for checking command-line parameters relevant to addition of the 'l' option. How about the patch adding compression/IO

Re: [Crash-utility] [RFC] makedumpfile, crash: LZO compression support

- Original Message - Hello Hatayama-san, How about the patch adding compression/IO time report? I intended it only for the presentation of this RFC. I think the above patch was posted only for this discussion, and I won't merge it into the makedumpfile. I'll post the

Re: [PATCH] crash: s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed

- Original Message - Unfortunately Mahesh is currently not online. We still have some time because Martin's kernel patch that introduces the change will go into Linux version 3.3. So perhaps you make your crash release without this patch. Michael Tell you what -- I'm going to

Re: [PATCH] crash: s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed

- Original Message - Hi Dave, On Thu, 2011-12-22 at 09:19 -0500, Dave Anderson wrote: - Original Message - Unfortunately Mahesh is currently not online. We still have some time because Martin's kernel patch that introduces the change will go into Linux

Re: [RESEND][PATCH] crash: Add LZO Compression Support

- Original Message - I'm sorry that I wrongly sended the previous mail in html format. I re-send the mail. == Hello Dave, This is LZO patch for crash utility. makedumpfile will support LZO compression in version 1.4.4, and it will be released this or next month. LZO patch

Re: [PATCH 0/5] crash: Small bundle of fixes for Xen

- Original Message - On Thu, Jul 05, 2012 at 11:15:29AM -0400, Dave Anderson wrote: - Original Message - Hi, It looks that Xen support for crash have not been maintained since 2009. I am trying to fix this. Here it is small bundle of fixes: - xen

Re: [PATCH 0/5] crash: Small bundle of fixes for Xen

- Original Message - On Thu, Jul 05, 2012 at 05:29:50PM +0200, Daniel Kiper wrote: On Thu, Jul 05, 2012 at 11:15:29AM -0400, Dave Anderson wrote: - Original Message - Hi, It looks that Xen support for crash have not been maintained since 2009. I am

Re: [PATCH 0/5] crash: Small bundle of fixes for Xen

- Original Message - - Original Message - On Thu, Jul 05, 2012 at 05:29:50PM +0200, Daniel Kiper wrote: On Thu, Jul 05, 2012 at 11:15:29AM -0400, Dave Anderson wrote: - Original Message - Hi, It looks that Xen support for crash have

Re: [PATCH v2 0/6] crash: Bundle of fixes for Xen

- Original Message - Hi, It looks that Xen support for crash have not been maintained since 2009. I am trying to fix this. Here it is bundle of fixes: - xen: Always calculate max_cpus value, - xen: Read only crash notes for onlined CPUs, - x86/xen: Read variables from

Re: [PATCH 0/5] crash: Bundle of fixes for Xen

- Original Message - Hi, Here is next bundle of fixes for crash Xen support: - xen: Fix page tables caching issues, - xen: Use init_tss array or per_cpu__init_tss, - xen: Use per_cpu__crash_notes or crash_notes array, - xen: Try hard to get max_cpus value, - xen: Use

Re: [PATCH v2 0/7] makedumpfile security key filtering with eppic

- Original Message - Hi Vivek, On 2012-11-14 20:24, Vivek Goyal wrote: On Thu, Nov 08, 2012 at 07:07:52PM +0530, Aravinda Prasad wrote: makedumpfile security key filtering enhancement - Add Eppic language support (formerly known as SIAL) to specify rules to scrub data in a

Re: [PATCH v2 0/7] makedumpfile security key filtering with eppic

- Original Message - struct key in include/linux/key.h holds authentication token/access credential/keyring. Suppose these entries should be scrubbed from the dumpfile. Then the keyring_name_hash hash table should be scanned and for each non-empty list, the entire list should be

Re: [PATCH v2 0/7] makedumpfile security key filtering with eppic

- Original Message - Another approach is to dynamically load libeppic library - similar way how crash does it. No major changes will be done to makedumpfile code, except the addition of --eppic flag. Upon specifying --eppic flag makedumpfile will dlopen libeppic.so, which will

Re: [RFC PATCH 0/8] remove vm_struct list management

? kdump's makedumpfile command would not even need to traverse the vmap_area rbtree, because it could simply look at the first vmap_area in the sorted vmap_area_list, correct? Dave Anderson ___ kexec mailing list kexec@lists.infradead.org http

Re: [RFC PATCH 0/8] remove vm_struct list management

- Original Message - On Mon, Dec 10, 2012 at 11:40:47PM +0900, JoonSoo Kim wrote: [..] So without knowing details of both the data structures, I think if vmlist is going away, then user space tools should be able to traverse vmap_area_root rb tree. I am assuming it is

makedumpfile bug with ppc64 CONFIG_SPARSEMEM_EXTREME

Our QA group recently ran into a makedumpfile problem while testing kdump/makedumpfile w/upstream 3.7.1 kernels, which had to do with the filtering of pages on a 12GB ppc64 system. The problem can be seen using -d31 on the vmcore.full ELF dumpfile: # makedumpfile -c -d31 -x vmlinux

Re: makedumpfile bug with ppc64 CONFIG_SPARSEMEM_EXTREME

- Original Message - Our QA group recently ran into a makedumpfile problem while testing kdump/makedumpfile w/upstream 3.7.1 kernels, which had to do with the filtering of pages on a 12GB ppc64 system. ... [ cut ] ... I haven't checked why the original math fails in the case of

Re: makedumpfile --dump-dmesg option broken on 3.5 kernels and later

- Original Message - Bouchard Louis louis.bouch...@canonical.com wrote: I now have what looks like a working patch for this issue. Thank to Dave Anderson (crash) and Eric Biederman (vmcore-dmesg) for having chewed most of the work for me. My only remaining problem is to be able

Re: [PATCH 0/2] crash: Bundle of fixes for Xen

- Original Message - Hi, Here is next bundle of fixes for crash Xen support: - xen: Improve calculation of beginning of virtual address space, - xen: Fix console buffer content length calculation. All patches were tested with Xen versions up to latest unstable. Daniel

kdump on ARM LPAE?

Does anybody know whether the kernel kdump facility works with 32-bit ARM LPAE kernels? Dave ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

Re: [BUG] [compressed kdump / SADUMP] makedumpfile header truncation error

- Original Message - On 09/17/2013 03:33 PM, HATAYAMA Daisuke wrote: (2013/09/17 16:12), Jingbai Ma wrote: On 09/17/2013 02:55 PM, HATAYAMA Daisuke wrote: int32_t, int64_t, uint64_t, etc ... are parts of C99 standard: http://en.wikipedia.org/wiki/C_data_types All there types

Re: [BUG] [compressed kdump / SADUMP] makedumpfile header truncation error

- Original Message - On 09/17/2013 09:23 PM, Dave Anderson wrote: - Original Message - On 09/17/2013 03:33 PM, HATAYAMA Daisuke wrote: (2013/09/17 16:12), Jingbai Ma wrote: On 09/17/2013 02:55 PM, HATAYAMA Daisuke wrote: int32_t, int64_t, uint64_t, etc

Re: [PATCH] crash utility: fix max_mapnr issue on system has over 44-bit addressing

- Original Message - The patch will add support for new compressed dumpfile header_version 6. This bug was posted here: http://lists.infradead.org/pipermail/kexec/2013-September/009587.html This patch will add a new field in struct kdump_sub_header. unsigned long max_mapnr;

Re: [PATCH / RFC] makedumpfile header to show LZO/snappy/zlib

- Original Message - On Fri, 20 Sep 2013 09:04:40 -0400 (EDT) Dave Anderson ander...@redhat.com wrote: - Original Message - Hello Dave, (2013/09/16 0:56), Dave Anderson wrote: With the advent of LZO and snappy compression support, it would

Re: [PATCH v2] crash utility: fix max_mapnr issue on system has over 44-bit addressing

. The max_mapnr_64 in the sub-header only exists in compressed kdump file format, so can't be used in diskdump file format. - Merge a patch from Dave Anderson that fixed bitmap_len issue. v1: - http://lists.infradead.org/pipermail/kexec/2013-September/009663.html Signed-off-by: Jingbai Ma

Re: [PATCH v3] crash utility: fix max_mapnr issue on system has over 44-bit addressing

diskdump_data. The max_mapnr_64 in the sub-header only exists in compressed kdump file format, so can't be used in diskdump file format. - Merge a patch from Dave Anderson that fixed bitmap_len issue. v1: - http://lists.infradead.org/pipermail/kexec/2013-September/009663.html Signed-off

Re: [PATCH 2/2] makedumpfile: exclude unused vmemmap pages (Cliff Wickman)

- Original Message - Date: Tue, 31 Dec 2013 17:36:02 -0600 From: Cliff Wickman c...@sgi.com To: kexec@lists.infradead.org, d.hatay...@jp.fujitsu.com, kumagai-atsu...@mxc.nes.nec.co.jp Subject: [PATCH 2/2] makedumpfile: exclude unused vmemmap pages Message-ID:

Re: [PATCH 2/2] makedumpfile: exclude unused vmemmap pages (Cliff Wickman)

- Original Message - On Thu, Jan 02, 2014 at 11:50:14AM -0500, Dave Anderson wrote: - Original Message - Date: Tue, 31 Dec 2013 17:36:02 -0600 From: Cliff Wickman c...@sgi.com To: kexec@lists.infradead.org, d.hatay...@jp.fujitsu.com, kumagai-atsu

Re: [Crash-utility] [PATCH 0/4] Enable use of crash on xen 4.4.0 vmcore

- Original Message - With the addition on PVH code to xen 4.4, domain.is_hvm no longer exists. This prevents crash from using a xen 4.4.0 vmcore. Patch 1 fixes this. Patch 2 is a minor fix in that outputing the offset in hex for domain_domain_flags is different. Patch 3 is a

Re: [Crash-utility] [PATCH 0/4] Enable use of crash on xen 4.4.0 vmcore

- Original Message - On 01/06/14 12:05, Dave Anderson wrote: - Original Message - With the addition on PVH code to xen 4.4, domain.is_hvm no longer exists. This prevents crash from using a xen 4.4.0 vmcore. Patch 1 fixes this. Patch 2 is a minor fix

[PATCH] makedumpfile: add -p references where appropriate in --help output

While the makedumpfile --help does have a couple references to snappy compression support, the output neglects to show the -p option in several examples. --- print_info.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/print_info.c b/print_info.c index

Re: [PATCH 2/2 V2] exclude unused vmemmap pages

- Original Message - provides some requested changes: - remove the automatic exclusion of page structures for memories over 1TB; it will only be done by explicit request (-e) - remove the -N option; no need to explicitly include unused vmemmap pages as they will be included by

Re: [Crash-utility] crash: struct command can read irrelevant pages.

- Original Message - Hello, Finally, I've found the cause of the issue I mentioned as below when makedumpfile v1.5.5 was released: 2. At first, the supported kernel will be updated to 3.12, but I found an issue while testing for v1.5.5, which seems that the page filtering

Re: [Crash-utility] crash: struct command can read irrelevant pages.

Hello Atsushi, I've committed a SLAB/SLUB kmem_cache-specific fix for this issue: https://github.com/crash-utility/crash/commit/c0b7a74fc13121203810d06d163550436b2d5476 which is queued for crash-7.0.6. Thanks, Dave - Original Message - - Original Message -

Re: [Crash-utility] crash: struct command can read irrelevant pages.

- Original Message - Hello Atsushi, I've committed a SLAB/SLUB kmem_cache-specific fix for this issue: https://github.com/crash-utility/crash/commit/c0b7a74fc13121203810d06d163550436b2d5476 which is queued for crash-7.0.6. Thanks Dave, I made sure that this patch solved

Re: [PATCH 0/3] add LPAE support for kexec and kernel (Liu Hua)

- Original Message - The patch series introduce LPAE support for user space utility kexec(the last) and ARM linux kernel(the others). I have tested the patch series in armA15 platform which have more than 4G memory. Hello Liu, I'm curious how you tested this? The crash utility

Re: [PATCH 0/3] add LPAE support for kexec and kernel (Liu Hua)

- Original Message - On 2014/3/27 22:04, Dave Anderson wrote: - Original Message - The patch series introduce LPAE support for user space utility kexec(the last) and ARM linux kernel(the others). I have tested the patch series in armA15 platform which have

Re: [BUG REPORT] kexec and makedumpfile can't detect PAGE_OFFSET on arm (Wang Nan)

- Original Message - Hi Atsushi and Simon, I find a problem about VMSPLIT on arm plarform, related to kexec and makedumpfile. When CONFIG_VMSPLIT_1G/2G is selected by kernel, PAGE_OFFSET is actually 0x4000 or 0x8000. However, kexec hard codes PAGE_OFFSET to 0xc000

Re: [BUG REPORT] kexec and makedumpfile can't detect PAGE_OFFSET on arm (Wang Nan)

- Original Message - On 2014/5/20 3:41, Dave Anderson wrote: - Original Message - Hi Atsushi and Simon, I find a problem about VMSPLIT on arm plarform, related to kexec and makedumpfile. When CONFIG_VMSPLIT_1G/2G is selected by kernel, PAGE_OFFSET

Re: uniquely identifying KDUMP files that originate from QEMU

- Original Message - From: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com To: ptesa...@suse.cz Cc: ler...@redhat.com, kexec@lists.infradead.org Subject: Re: uniquely identifying KDUMP files that originate from QEMU Message-ID:

Re: uniquely identifying KDUMP files that originate from QEMU

- Original Message - On 11/12/14 15:09, Dave Anderson wrote: - Original Message - From: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com To: ptesa...@suse.cz Cc: ler...@redhat.com, kexec@lists.infradead.org Subject: Re: uniquely identifying KDUMP files that originate

Re: uniquely identifying KDUMP files that originate from QEMU

- Original Message - adding back a few CC's because this discussion is useful On 11/12/14 19:43, Petr Tesarik wrote: V Wed, 12 Nov 2014 15:50:32 +0100 Laszlo Ersek ler...@redhat.com napsáno: On 11/12/14 09:04, Petr Tesarik wrote: On Wed, 12 Nov 2014 12:08:38 +0900 (JST)

Re: [Crash-utility] uniquely identifying KDUMP files that originate from QEMU

- Original Message - Can you fetch that in crash? If you can, then there's nothing to do on the qemu side (and I'll have to apologize for spamming a bunch of lists :/). Well, let's be clear -- I was the one who put you up to it... But no apology is required -- and in fact, if

Re: uniquely identifying KDUMP files that originate from QEMU

- Original Message - From: Dave Anderson ander...@redhat.com Subject: Re: uniquely identifying KDUMP files that originate from QEMU Date: Wed, 12 Nov 2014 09:09:34 -0500 - Original Message - From: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com To: ptesa...@suse.cz

Re: Failure to crashdump under Centos-6.4 x86_64 with kernel 3.12.30

- Original Message - My kernel crashdumps don't work with vanilla 3.12.30 on a 256GB x86_64 intel box. Centos-6.4. With the standard makedumpfile, makedumpfile segfaults, and no output is written to disk. with makedumpfile 1.5.7, kexec-tools-2.0.8, and crash 7.0.2 I actually get

Dmesg not being dumped

- Original Message - Hi, On 08/19/2015 12:02 PM, Baoquan He wrote: On 08/19/15 at 09:21am, Nikolay Borisov wrote: Hello, I've recently noticed that when creating crashdumps the dmesg is not being saved. The error reported is this: Missing the struct log size export.

Re: Dmesg not being dumped

- Original Message - On 08/20/2015 04:04 PM, Dave Anderson wrote: The vmcoreinfo data strings were initially located in an ELF note in /proc/vmcore. When makedumpfile -c was run on /proc/vmcore, it copied those ELF notes into the compressed kdump header, and you have

Re: Dmesg not being dumped

- Original Message - On 08/19/2015 11:38 PM, Dave Anderson wrote: - Original Message - Hi, On 08/19/2015 12:02 PM, Baoquan He wrote: On 08/19/15 at 09:21am, Nikolay Borisov wrote: Hello, I've recently noticed that when creating crashdumps the dmesg

Re: [PATCH V6] makedumpfile: exclude page structures of non-dumped pages

- Original Message - done) > > The only disadvantage is that various options of the crash 'kmem' command that > walk lists of page structures) will not work. > Version 7.0.9 of crash is already patched to issue a warning about such > commands > when the

Re: [Crash-utility] Support for dynamic allocations of 'struct fpu'

- Original Message - > Hello, > > This is a follow-up report of the issue I found in the release test > for makedumpfile-1.5.9. The original report was posted in kexec-ML: > > http://lists.infradead.org/pipermail/kexec/2015-October/014620.html > > > o Support new kernels > > - The

Re: [Crash-utility] Support for dynamic allocations of 'struct fpu'

- Original Message - > > > - Original Message - > > Hello, > > > > This is a follow-up report of the issue I found in the release test > > for makedumpfile-1.5.9. The original report was posted in kexec-ML: > > > >

Re: [PATCH V7] makedumpfile: exclude page structures of non-dumped pages

- Original Message - > >On Wed, Oct 28, 2015 at 04:38:24AM +, Atsushi Kumagai wrote: > >> Hello Cliff, > >> > >> >From: Cliff Wickman > >> > > >> >Applies to the development branch as of 10/13/2015. > >> >Incorporates review 10/22 by kumagai-atsushi. > >>

Re: [PATCH V5] makedumpfile: exclude page structures of non-dumped pages

- Original Message - > > Applies to the development branch as of 10/13/2015. > > This patch adds a -e option to makedumpfile. > The -e option excludes kernel pages that contain nothing but kernel page > structures for pages that are not being included in the dump. ... [ cut ] ... > >

Re: [PATCH] makedumpfile: support _count -> _refcount rename in struct page

l is now broken as well. FYI, crash was fixed upstream a few weeks ago: commit 8ceb1ac628bf6a0a7f0bbfff030ec93081bca4cd Author: Dave Anderson <ander...@redhat.com> Date: Mon May 23 11:23:01 2016 -0400 Fix for Linux commit 0139aa7b7fa12ceef095d99dc36606a5b10ab83a, which rename

makedumpfile: 4.5 kernel commit breaks page filtering

Hello Atsushi, I've recently had a couple 4.5-era vmcores issues reported to me as crash bugs because they generate numerous initialization-time errors of the type: crash: page excluded: kernel virtual address: 880075459000 type: "fill_task_struct" Initially I thought it was related

Re: makedumpfile: 4.5 kernel commit breaks page filtering

s the other two use !isAnon(). So if my logic is correct, if you try to filter out page-cache pages as well -- i.e., with "-d23" -- worst case it may result in some pages *not* being filtered. And I'm not even sure of that, given the page->flags checks that go along with it. Da

Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled

- Original Message - > > That being said, my recent 4.8 and 4.9 KASLR testing has been on live > systems and compressed kdumps, so the old tried-and-true manner of > calculating the phys_base from the ELF PT_LOAD segments apparently > no longer works with KASLR. > > It would be so

Re: [PATCH 2/2] makedumpfile: Clean up unused KERNEL_IMAGE_SIZE

- Original Message - > The old MODULES_VADDR need be decided by KERNEL_IMAGE_SIZE when kaslr > enabled. Now MODULES_VADDR is not needed any more since Pratyush makes > all VA to PA converting done by page table lookup. So remove its related > code. Hi Bao, I'm not clear on this. The

Re: [PATCH 2/2] makedumpfile: Clean up unused KERNEL_IMAGE_SIZE

- Original Message - > On 11/10/16 at 01:15am, Atsushi Kumagai wrote: > > Hello Baoquan, > > > > >> > The old MODULES_VADDR need be decided by KERNEL_IMAGE_SIZE when kaslr > > >> > enabled. Now MODULES_VADDR is not needed any more since Pratyush makes > > >> > all VA to PA converting

Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

ctions virtual addresses > > [snip]] > > > > > } > > > > > > /* arch-dependent functionality related to kexec file-based syscall */ > > > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c > > > index 5616755..8ad3a29e 100644 >

Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled

- Original Message - > > I put the cped-vmcore/vmlinux here: > https://people.redhat.com/~ruyang/test/ > > Adding Dave Anderson for any comments about the vmcore correctness from > crash point of view.. > As it turns out, the vmcore.makedumpfile can be read

Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

- Original Message - > Hi Dave, > > On 11/01/16 at 10:13am, Dave Anderson wrote: > > > > > > > > But we have this in mainline which also introduced the VMCOREINFO > > > > numbers, can you send a patch to revert them? &

Re: Re: [Makedumpfile PATCH v2] x86_64: Take care of init_level4_pgt rename in kernel

- Original Message - > > Ccing Dave, not sure if crash utility also need update about this > issue.. Hi Pratyush, Yes it does, I fixed it upstream a few weeks ago: commit a16324a2f05c0947a83e26a5de7c756de4603da9 Author: Dave Anderson <ander...@redhat.com> Date:

[makedumpfile PATCH RFC v0.1] Implemented the --fill-excluded-pages= feature

- Original Message - > When a page is excluded by any of the existing dump levels, > that page may still be written to the ELF dump file, depending > upon the PFN_EXCLUDED mechanism. > > The PFN_EXCLUDED mechanism looks for N consecutive "not > dumpable" pages, and if found, the

Re: [Crash-utility] [PATCH] xen: Add support for domU with Linux kernel 3.19 and newer

- Original Message - > crash patch c3413456599161cabc4e910a0ae91dfe5eec3c21 (xen: Add support for > dom0 with Linux kernel 3.19 and newer) from Daniel made crash utility > support xen dom0 vmcores after linux kernel commit > 054954eb051f35e74b75a566a96fe756015352c8 (xen: switch to linear

Re: makedumpfile: support for newer kernels [v4.9 onwards]

- Original Message - > Hi Abhishek, > > On Thursday 08 June 2017 11:30 AM, Abhishek Shah wrote: > > Hi Pratyush, > > > I am using yocto(2.3 version) to build makedumpfile, which fetches v1.6.1 > makedumpfile and also applys some patches including arm64 specific >

Re: makedumpfile saving vmcore fails with dynamically allocated mem_section (was: Re: [PATCH] handle renamed init_level4_pgt -> init_top_pgt)

- Original Message - > On 01/05/18 at 09:16am, Dave Anderson wrote: > > > > > > - Original Message - > > > On 01/03/18 at 03:21pm, Dave Anderson wrote: > > > > > > > > > > > > - Original Message

Re: makedumpfile saving vmcore fails with dynamically allocated mem_section (was: Re: [PATCH] handle renamed init_level4_pgt -> init_top_pgt)

- Original Message - > On 01/03/18 at 03:21pm, Dave Anderson wrote: > > > > > > - Original Message - > > > > > On 01/02/18 at 05:08pm, Baoquan He wrote: > > > > On 01/02/18 at 04:57pm, Dave Young wrote: > > > > &g

Re: makedumpfile saving vmcore fails with dynamically allocated mem_section (was: Re: [PATCH] handle renamed init_level4_pgt -> init_top_pgt)

d, this should ensure > makedumpfile maybe crash tool works without any modifications, > waiting for feedback from Atsushi, also ccing Dave for crash utility > potential issue. Yeah, I ran into that issue when testing 4.15, and fixed it upstream: https://github.com/crash-utility/c

Re: [PATCH net-next v2 0/2] kernel: add support to collect hardware logs in crash recovery kerne

- Original Message - > > On Tuesday, March 03/27/18, 2018 at 18:47:34 +0530, Eric W. Biederman wrote: > > Rahul Lakkireddy writes: > > > > > On Saturday, March 03/24/18, 2018 at 20:50:52 +0530, Eric W. Biederman > > > wrote: > > >> > > >> Rahul

Re: [PATCH] makedumpfile/ppc64: increase MAX_PHYSMEM_BITS to > 128TB

- Original Message - > > * Required for kernel 4.19 > > With kernel commit 7d4340bb92a9 ("powerpc/mm: Increase MAX_PHYSMEM_BITS > to 128TB with SPARSEMEM_VMEMMAP config"), MAX_PHYSMEM_BITS is bumped up > to 47. Make the appropriate update here. > > Signed-off-by: Hari Bathini > --- >

Re: [PATCH 1/2 v6] kdump: add the vmcoreinfo documentation

- Original Message - > On Mon, Jan 14, 2019 at 03:26:32PM -0500, Dave Anderson wrote: > > No. It needs *both* the vmlinux file and the vmcore file in order to read > > kernel > > virtual memory, so just having a kernel virtual address is insufficient. > > &g

  1   2   >