Re: [Crash-utility] [PATH v4 2/2] arm64: add 4-level translation

- Original Message - > On Tue, May 31, 2016 at 03:30:44PM -0400, Dave Anderson wrote: > > > > This patch looks good -- if it wasn't layered on top of the KASLR patch, > > I would check it into github. > > This patch is almost independent from KASLR suppor

Re: [Crash-utility] [PATH v4 1/2] arm64: fix kernel memory map handling for kaslr-enabled kernel

- Original Message - > In kernel v4.6, Kernel ASLR (KASLR) is supported on arm64, and the start > address of the kernel image can be randomized if CONFIG_RANDOMIZE_BASE is > enabled. > Even worse, the kernel image is no more mapped in the linear mapping, but > in vmalloc area (i.e.

Re: [Crash-utility] [PATH v3 0/3] arm64: fix kernel memory map handling for kaslr-enabled kernel

Takahiro, I am out of the office until next Tuesday, so I won't be able to comment on the v3 patch until then. One thing, though, is that I already fixed the page _count to _refcount issue in the github repo a few days ago. Thanks, Dave > Not a big jump from v2, but ... > > Chnages in v3: >

Re: [Crash-utility] [PATCH v2] arm64: fix kernel memory map handling for kaslr-enabled kernel

- Original Message - > > > > > 3) Backtracing a 'panic'ed task fails: > > > > > crash> bt > > > > > PID: 999TASK: ffe960081800 CPU: 0 COMMAND: "sh" > > > > > bt: WARNING: corrupt prstatus? pstate=0x8000, but no user frame > > > > > found > > > > > bt: WARNING: cannot

Re: [Crash-utility] [PATCH v2] arm64: fix kernel memory map handling for kaslr-enabled kernel

- Original Message - > > > > Are you using a mainline kernel (final v4.6, not -rcX)? > > Good point. When I configured my arm64 test system, I installed the latest > Fedora kernel available at the time (4.6.0-0.rc7.git2.1.fc25), but it is based > upon linux-4.5.tar.xz. I see now that

Re: [Crash-utility] [PATCH v2] arm64: fix kernel memory map handling for kaslr-enabled kernel

- Original Message - > On Tue, May 24, 2016 at 01:59:06PM -0400, Dave Anderson wrote: > > > > - Original Message - > > > Yet some issues, but ... > > > > > > > Hi Takahiro, > > > > Here are my general comments on m

Re: [Crash-utility] [PATCH v1] arm64: fix kernel memory map handling for kaslr-enabled

- Original Message - > On Tue, May 24, 2016 at 09:35:54AM -0400, Dave Anderson wrote: > > > > > > - Original Message - > > > > > > > > > > Now that PHYS_OFFSET is defined as "memstart_addr", we can get the >

Re: [Crash-utility] [PATCH v1] arm64: fix kernel memory map handling for kaslr-enabled

- Original Message - > > > > > > Now that PHYS_OFFSET is defined as "memstart_addr", we can get the value > > > if we can access this symbol (on a live system). > > > > When PHYS_OFFSET/memstart_addr is bumped up from the actual base of > > physical > > memory, is the physical

Re: [Crash-utility] [PATCH v1] arm64: fix kernel memory map handling for kaslr-enabled

- Original Message - > On Fri, May 20, 2016 at 03:06:39PM -0400, Dave Anderson wrote: > > > > > > Hi Takahiro, > > > > Welcome to the mailing list -- you are a most valuable addition. > > > > To others in the list, Takahiro and I have been

Re: [Crash-utility] [PATCH v1] arm64: fix kernel memory map handling for kaslr-enabled

Hi Takahiro, Welcome to the mailing list -- you are a most valuable addition. To others in the list, Takahiro and I have been communicating offline for a couple weeks, and I convinced him to join us. He works on both kexec-tools and the crash utility for Linaro on the ARM64 architecture. If

Re: [Crash-utility] [PATCH 1/2] memory.c: fix missing printf flags in INFO message in page_flags_init_from_pageflag_names()

OK thanks, Andrey -- queued for crash-7.1.6: https://github.com/crash-utility/crash/commit/7136bf8495948cb059e5595b8503f8ae37019fa1 Dave - Original Message - > On 19 May, Dave Anderson wrote: > > > > Hi Andrey, > > > > Thanks for this patch. Ca

Re: [Crash-utility] [PATCH 1/2] memory.c: fix missing printf flags in INFO message in page_flags_init_from_pageflag_names()

Hi Andrey, Thanks for this patch. Can you tell me what "kmem -g" shows? Dave - Original Message - > Signed-off-by: Andrey Skvortsov > --- > memory.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/memory.c b/memory.c > index

Re: [Crash-utility] [PATCH 0/2] qemu: Parse necessary sections in crash added in qemu

o/crash-utility > > > > Hi Pankaj, > > I suppose I can take the patch. But, given the advent of "virsh dump > --memory-only" > back in 2012, and more recently, Oleg's added support for QEMU ramdumps by > specifying > a memory-backend-file object to the qemu-

Re: [Crash-utility] [PATCH 0/2] qemu: Parse necessary sections in crash added in qemu

a memory-backend-file object to the qemu-kvm command: commit 89ed9d0a7f7da4578294a492c1ad857244ce7352 Author: Dave Anderson <ander...@redhat.com> Date: Wed May 4 11:50:19 2016 -0400 Introduction of support for "live" ramdump files, such as those that are specified by the QEMU mem-path argument of a

Re: [Crash-utility] [PATCH v3 0/9] teach crash to work with "live" ramdump

- Original Message - > n 05/04, Dave Anderson wrote: > > > > Hi Oleg, > > > > The v3 patchset has been queued for crash-7.1.6: > > > > > > https://github.com/crash-utility/crash/commit/89ed9d0a7f7da4578294a492c1ad857244ce7352 > > >

Re: [Crash-utility] Fix loading qemu's dump-guest-image

- Original Message - > qemu can make elf vmcore without kdump in kernel. So kernel may not > have "kexec_crash_image" symbol. > > Without this patch, kdump_backup_region_init() stops main_loop with > error. > Queued for crash-7.1.6:

Re: [Crash-utility] [PATCH v3 0/9] teach crash to work with "live" ramdump

Hi Oleg, The v3 patchset has been queued for crash-7.1.6: https://github.com/crash-utility/crash/commit/89ed9d0a7f7da4578294a492c1ad857244ce7352 I added some documentation in help.c for "crash -h", and in the crash.8 man page. Also, I changed ACTIVE() to LOCAL_ACTIVE() in the

Re: [Crash-utility] [PATCH v3 0/9] teach crash to work with "live" ramdump

- Original Message - > On 05/03, Dave Anderson wrote: > > > > > Based on your comments, please see the interdiff below. > > > > Oleg, > > > > Can you just give me a fresh patchset based upon the upstream git repo? > > Hmm. Did you ge

Re: [Crash-utility] PATCH v2 00/10] teach crash to work with "live" ramdump

- Original Message - > On 05/02, Oleg Nesterov wrote: > > > > On 05/02, Dave Anderson wrote: > > > > > > > So how should I define LOCAL_ACTIVE() ? As for this patchset I can > > > > equally do > > > > > > >

Re: [Crash-utility] PATCH v2 00/10] teach crash to work with "live" ramdump

- Original Message - > Hmm. I thought that you were already agree on MEMSRC_LOCAL usage. > > On 05/02, Dave Anderson wrote: > > > > > > @@ -124,6 +124,7 @@ fd_init(void) > > > > > > > > if (!pc->dumpfile) { &g

Re: [Crash-utility] PATCH v2 00/10] teach crash to work with "live" ramdump

dition your patch is bringing ? > Broadcom brought the support for raw ramdump, well you know justpreparing ELF > header and sparse support. > > so just wanted to understand how what you patch does, it addresses live dump > ? could you elaborate on it ? > > Regards, > Oza. > >

Re: [Crash-utility] PATCH v2 00/10] teach crash to work with "live" ramdump

- Original Message - > Hi Dave, > > please consider V2, I tried to address your comments. > > Oleg. Hi Oleg, This looks pretty good, but I do have a couple of questions/comments. In [PATCH v2 02/10]: @@ -124,6 +124,7 @@ fd_init(void) if (!pc->dumpfile) {

Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump

- Original Message - > On 04/28, Dave Anderson wrote: > > > > > OK, good. So can't you apply 1-7 first? so that we can finish this part > > > and then > > > add the support for live dumpfiles. > > > > No, I don't commit things piecemeal

Re: [Crash-utility] [PATCH v2 03/10] back_trace: don't check /proc if !LOCAL_ACTIVE()

- Original Message - > On 04/28, Dave Anderson wrote: > > > > > > > --- a/kernel.c > > > +++ b/kernel.c > > > @@ -2902,7 +2902,7 @@ back_trace(struct bt_info *bt) > > > > > > if (ACTIVE() && !INSTA

Re: [Crash-utility] [PATCH v2 03/10] back_trace: don't check /proc if !LOCAL_ACTIVE()

- Original Message - > > > - Original Message - > > On 04/25, Oleg Nesterov wrote: > > > > > > - if (ACTIVE() && !INSTACK(esp, bt)) { > > > + if (LOCAL_ACTIVE() && !INSTACK(esp, bt)) { > > > > Of course, this is wrong, please see v2 below. > > > >

Re: [Crash-utility] [PATCH v2 03/10] back_trace: don't check /proc if !LOCAL_ACTIVE()

- Original Message - > On 04/25, Oleg Nesterov wrote: > > > > - if (ACTIVE() && !INSTACK(esp, bt)) { > > + if (LOCAL_ACTIVE() && !INSTACK(esp, bt)) { > > Of course, this is wrong, please see v2 below. > >

Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump

- Original Message - > sorry for delay Dave, > > On 04/27, Dave Anderson wrote: > > > > > > > But not on x86-64, is_ramdump() insists on ramdump_to_elf() even if > > > > > we could > > > > > use read_ramdump(), and ra

[Crash-utility] [ANNOUNCE] crash version 7.1.5 is available

Download from: http://people.redhat.com/anderson or https://github.com/crash-utility/crash/releases The github master branch serves as a development branch that will contain all patches that are queued for the next release: $ git clone git://github.com/crash

Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump

- Original Message - > On 04/27, Dave Anderson wrote: > > > > > > OK, so we're running on a host machine that has one of these memory > > > > files > > > > that is accessible as a regular file. > > > > >

Re: [Crash-utility] [PATCH] arm64: support MAX_PHYSMEM_BITS=48

- Original Message - > Hi, > > This match update made in file 'arch/arm64/include/asm/sparsemem.h'. > > commit 07a15dd55a3d65f81b4b09eab293f4afc720b082 > arm64: mm: update max pa bits to 48 Johan, Queued for crash-7.1.5:

Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump

- Original Message - > On 04/26, Dave Anderson wrote: > > > > > > - Original Message - > > > On 04/26, Dave Anderson wrote: > > > > > > > > > No, just a regular file, qemu creates it and does mmap(MAP_SHARED) on >

Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump

- Original Message - > On 04/26, Dave Anderson wrote: > > > > > No, just a regular file, qemu creates it and does mmap(MAP_SHARED) on it. > > > > > > > that constantly contains the > > > > current contents of the guest's physical memory?

Re: [Crash-utility] [PATCH V3 0/3] sparc64 support for crash utility

Hi Dave, Your 3-part patchset is queued for crash-7.1.5 in these two commits: https://github.com/crash-utility/crash/commit/569002249b1d57162a1e94f529d295828d4e0253 https://github.com/crash-utility/crash/commit/fd2f8ef41e76c1276d9bbd33dfcff94dd6da9439 I hope to release crash-7.1.5

Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump

- Original Message - > On 04/26, Dave Anderson wrote: > > > > I didn't write this code, but here's how I understand it. > > Thanks Dave, I'll read your explanation tomorrow, I need to run away again. > > > > OK. So I am running the rhel7 gues

Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump

- Original Message - > On 04/26, Dave Anderson wrote: > > > > > But all the LOCAL_ACTIVE changes in 1-7 do not care about the details of > > > "live" > > > mechanism at all. So I still think we need a generic helper which should > >

Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump

- Original Message - > On 04/26, Dave Anderson wrote: > > > > > Yes. And to remind, MEMORY-IMAGE@ADDRESS (which is even documented in > > > crash.8 as > > > "raw RAM dumpfile that has no header information") doesn't work on >

Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump

- Original Message - > On 04/26, Dave Anderson wrote: > > > > > > > and that is what this part of changelog > > > > > > The usage of CRASHBUILTIN doesn't look nice, we need to cleanup > > > this logic. I hope we can do th

Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump

- Original Message - > On 04/26, Dave Anderson wrote: > > > > > OK. Suppose we add ACTIVE_QEMU() helper. IMO this is a bad idea in any > > > case, the core > > > code should not even know that this kernel runs under qemu. Nevermind, > > > su

Re: [Crash-utility] [PATCH V3 0/3] sparc64 support for crash utility

Dave, I'm about to check your stuff in, but one additional item needs to be added to configure.c for the crash.spec file. What's the proper sparc64 name string that should be added to the "ExclusiveArch:" list? Thanks, Dave - Original Message - > These patches add support for the

Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump

- Original Message - > On 04/26, Dave Anderson wrote: > > > > > Ah. Yes, the usage of CRASHBUILTIN is ugly, and I tried to document this. > > > > > > We need the new (say) RAW_MEM_DUMP flag. We can't use RAMDUMP because it >

Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump

- Original Message - > On 04/26, Dave Anderson wrote: > > > > > But let me also say that there is nothing qemu-specific in this series. > > > Except > > > it happens to work with the recent memory-backend-file qemu option. > > > > > &

Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump

- Original Message - > On 04/25, Dave Anderson wrote: > > > > As I see it, this facility is simply another LIVE_SYSTEM memory source, > > of which there currently are /dev/mem, /proc/kcore and /dev/crash. > > Yes, if we are talking about 09/10 and 10/1

Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump

- Original Message - > On 04/25, Dave Anderson wrote: > > > > I see that your overloading the ramdump.c file, but the ramdump facility was > > proposed and added by companies that use a firmware-based facility for > > dumping > > raw ARM/ARM64/MIPS R

Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump

- Original Message - > Dave, sorry I need to run away. I'll reply tomorrow. And I need to > actually read your emails first, perhaps I misunderstood you... > > Just one note, > > On 04/25, Dave Anderson wrote: > > > > As I see it, this facility is sim

Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump

Hi Oleg, Just to (maybe) clarify my first reply... As I see it, this facility is simply another LIVE_SYSTEM memory source, of which there currently are /dev/mem, /proc/kcore and /dev/crash. The essential difference between them is the pc->readmem plugin: /dev/mem -> read_dev_mem

Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump

- Original Message - > Hi Dave, > > Recently I used crash-tool for the first time and I was pleasantly surprised, > it really looks like a very useful and handy debugging tool ;) > > And I was surprised again when I figured out that it can be used to debug the > live system on the same

Re: [Crash-utility] [PATCH] ARM64 support for 3-level page tables with 64K pages

- Original Message - > Adds ARM64 support for 3-level page tables with 64K pages and 48 VA bits. Nicely done, Jim. Queued for crash-7.1.5: https://github.com/crash-utility/crash/commit/ab91852f945bfecfa0bca6a42253fbecb38723db Thanks, Dave > --- > arm64.c | 126 >

Re: [Crash-utility] [PATCH] Make vm -p work without swap

- Original Message - > Rabin Vincent writes: > > On kernels without swap, vm -p currently errors out with the message > "nr_swapfiles doesn't exist in this kernel". By handling this case > gracefully instead of erroring out, we make it work on such kernels.

Re: [Crash-utility] [RFC PATCH] struct: Fix handing of percpu symbols

- Original Message - > > > - Original Message - > > On Mon 2016-04-18 11:22 -0400, Dave Anderson wrote: > > > > Hi Dave, > > > > > I may be missing something, but it seems like you just need it to > > > calculate > > &

Re: [Crash-utility] [PATCH 1/2] Fix cpu_slab freelist handling on SLUB

- Original Message - > OGAWA Hirofumi writes: > > >> I'm thinking we should clarify that error message, perhaps by storing the > >> cpu > >> number in si->cpu, and displaying it when si->slab is NULL? > > > > Just a idea for now though (means not tested

Re: [Crash-utility] [PATCH 1/2] Fix cpu_slab freelist handling on SLUB

- Original Message - > Dave Anderson <ander...@redhat.com> writes: > > > - Original Message - > >> OGAWA Hirofumi <hirof...@mail.parknet.co.jp> writes: > >> > >> OK. More simpler proof, the following is enough to convince

Re: [Crash-utility] [PATCH 1/2] Fix cpu_slab freelist handling on SLUB

- Original Message - > OGAWA Hirofumi writes: > > OK. More simpler proof, the following is enough to convince you? No, I'm a believer. I could pretty much verify your count by looking at the task_struct slab cache. Interesting though, I was looking a

Re: [Crash-utility] [RFC PATCH] struct: Fix handing of percpu symbols

- Original Message - > On Mon 2016-04-18 11:22 -0400, Dave Anderson wrote: > > Hi Dave, > > > I may be missing something, but it seems like you just need it to calculate > > cpuaddr each time through the loop, and then you're done with it. But then &g

Re: [Crash-utility] [V3] Add the proccgroup extension

ng the coredump files. > > Regards, > Nikolay > Nikolay, I've posted your module on my extensions page here: http://people.redhat.com/anderson/extensions.html#SHOWCG It's only "final" if you don't bother to keep it working/updated as time goes by. Whenever you

Re: [Crash-utility] [RFC PATCH] struct: Fix handing of percpu symbols

- Original Message - > Hi Dave, > > > When a percpu symbol is of type pointer, the 'struct' command does > not generate the expected output. For example: > Aaron, I haven't gotten a chance to actually test this patch, but this part bothers me: + if (typename && (ptype

Re: [Crash-utility] [PATCH 1/2] Fix cpu_slab freelist handling on SLUB

Can you show a before-and-after example of the "kmem -s" and "kmem -S" output of a particular slab where your patch makes a difference? Thanks, Dave - Original Message - > Hi, > > SLUB cpu_slab has 2 freelist. One is cpu_slab->freelist for local > cpu. One is cpu_slab->page->freelist

Re: [Crash-utility] [PATCH 2/2] Update extensions/defs.h

This patch is not relevant. The extensions/defs.h in extensions is set up as a link to the top-level defs.h by extensions/Makefile. It is not part of the crash source tree. - Original Message - > > --- > > extensions/defs.h | 49 ++---

Re: [Crash-utility] [Patch 1/2] Request data structures of particular size. GDB part

- Original Message - > Hello Dave, > > I've rewritten the mentioned logic, now crash communicates with gdb by means > of gdb_interface. Hello Alexandr, I've been playing with your patch for the last couple of days, and in the interest of getting it checked in without us having to go

Re: [Crash-utility] [PATCHv2] Add the proccgroup extension

the cgroups. Both are the same odd-ball interim Fedora 3.13.0-0.rc1.git2.1.fc20 kernel, and no sources exist that I am aware of. Here are the vmlinux and vmcore if you want to play with the dumpfile: http://people.redhat.com/anderson/nborisov Dave -- Crash-utility mailing list Crash-utility@re

Re: [Crash-utility] [PATCHv2] Add the proccgroup extension

- Original Message - ... [ cut ] ... > > And lastly, I only have one 3.14-based kernel, which shows this: > > > > crash> sys | grep RELEASE > >RELEASE: 3.14.0-rc1+ > > crash> showcg > > showcg: zero-size memory allocation! (called from 7f3280273719) > > crash> > > > >

Re: [Crash-utility] [PATCHv2] Add the proccgroup extension

ng is the cgroup name and path? I don't know -- that's up to you. Also, you don't have to post your module as a patch to the extensions subdirectory. I'm not going to add the file to the crash sources contained in the tar.gz or src.rpm releases, but rather I will post your module source file, and

Re: [Crash-utility] wrong values shown by kmem -s

- Original Message - > > > > In your test code, you could simply NOT initialize the total_objects offset > > and see what happens. > > > Yes that shows the negative ALLOCATED values. One more minor change to > the previous patch was required (attached). > What I have tested and confirmed

Re: [Crash-utility] wrong values shown by kmem -s

- Original Message - > > > > While this is an improvement over your last post, there are still issues > > with this patchset. I've been testing it with a wide range of stashed > > vmcores, and I see problems with all of the old 2.6.24 vmcores. Those > > kernels used an early version of

Re: [Crash-utility] [PATCH] Add the proccgroup extension

- Original Message - > Initial version of a crash module which can be used to show which cgroups > is the currently active process member of. > --- > Hello this is a simple crash extension that I hacked up over the weekend, in > my > case when I look at kernel crash dump I want to

Re: [Crash-utility] [PATCH] Fix irq -s for v4.2+

- Original Message - > From: Rabin Vincent > > Since v4.2, irq_data is no longer the first element in irq_desc, because > there is now an irq_common_data before it. So we need to get the offset > of irq_data in irq_desc. > > Side note: Since v4.3, affinity (used by

Re: [Crash-utility] [Patch 0/2] Request data structures of particular size.

- Original Message - > > > - Original Message - > > Dave, > > > > thank you for your comment. I've also reviewed the set of existing gdb > > functions more carefully. Looks like it wasn't necessary to modify existing > > code in gdb. It suffice to use another function from the

Re: [Crash-utility] [Patch 0/2] Request data structures of particular size.

- Original Message - > Dave, > > thank you for your comment. I've also reviewed the set of existing gdb > functions more carefully. Looks like it wasn't necessary to modify existing > code in gdb. It suffice to use another function from the same structure (it > hasn't been used before -

Re: [Crash-utility] [Patch 0/2] Request data structures of particular size.

- Original Message - > Hello Dave, > > Here is the brief background for the patch. > > We had a problem - there was a page which contained some structure which we > weren't able to identify, > but we could specify approximate size of this structure. Also it might be > said that this

Re: [Crash-utility] Please subscribe

You can set up your own subscription at https://www.redhat.com/mailman/listinfo/crash-utility, but I see that you already are subscribed, at the address you sent, and at what appears to be another address of yours @live.com. Dave - Original Message - > > > > > > > > > > >

Re: [Crash-utility] Retrying /proc values from kdump file

- Original Message - > One of the specific items I wanted is /proc/buddyinfo. Well, it looks like /proc/buddyinfo date comes down to the functions in the kernel's seq_operations structure, where: proc_create("buddyinfo", S_IRUGO, NULL, _file_operations); leads to: static

Re: [Crash-utility] Retrying /proc values from kdump file

- Original Message - > Is it possible to get the /proc data from the saved crash dump file? > > -- > Mahmoud Hanafi > It would be helpful if you could be more specific, but generally speaking, the data displayed by /proc files comes from kernel data structures, and all kernel data

Re: [Crash-utility] [Patch V2 0/2] sparc64 support for crash utility

Dave, Can you write me up a header for sparc64.c that has a GPL statement and any desired copyright lines? No need for a full patch repost, just the header. Thanks, Dave - Original Message - > These patches add support for the sparc64 architecture. > > This supports running against

Re: [Crash-utility] wrong values shown by kmem -s

- Original Message - > On Tue, Mar 15, 2016 at 8:08 PM, vinayak menon > wrote: > >> > >> Although looking at it now, get_slabinfo() doesn't seem to take into > >> account > >> the objects in the per_cpu caches? > >> > >> Anyway, 200 of 200 is clearly wrong. >

Re: [Crash-utility] [PATCH] crash: add python wrapper script

Alexey, I'm not sure what you want me to do with this. Seems like a good candidate to be put on the upstream web page, maybe in the "Python Scripts" section, separated from, but next to the "mpykdump.so" section. Dave - Original Message - > Add simple script with caching (just one

Re: [Crash-utility] crash problems with linux-4.5

COMM > > 0 0 0 81c0f4c0 RU 0.0 0 0 [swapper/0] > crash> > > Any ideas? > > I'm using top-o-tree from Dave's git repo > https://github.com/crash-utility/crash.git: > > commit 04ab5c560a58246e782509d99214afcaf8462b4c > Auth

Re: [Crash-utility] crash problems with linux-4.5

> > > Any ideas? > > > > > > I'm using top-o-tree from Dave's git repo > > > https://github.com/crash-utility/crash.git: > > > > > > commit 04ab5c560a58246e782509d99214afcaf8462b4c > > > Author: Dave Anderson <ander...@redhat

Re: [Crash-utility] crash: vz extension for OpenVZ kernels: Vz7 support

- Original Message - > Dear Dave, > > could you please update vz.c extension on your site. > New version supports RHEL7-based Vz7 kernels. > > Thank you, > Vasily Averin Done. Thanks, Dave > > On 30.04.2015 18:57, Dave Anderson wrote: > >

Re: [Crash-utility] ARM64 (odroid-c2) crash fails to read live kernel

- Original Message - > root@odroid64-pre:~/crash-7.1.4# ./crash /proc/kcore > > crash 7.1.4 > Copyright (C) 2002-2015 Red Hat, Inc. > Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation > Copyright (C) 1999-2006 Hewlett-Packard Co > Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited

Re: [Crash-utility] ARM64 (odroid-c2) crash fails to read live kernel

- Original Message - > root@odroid64-pre:~/crash-7.1.4# ./crash --minimal > crash> rd linux_banner 30 > ffc00186a090: 00160102 5018 .P.. > ffc00186a0a0: 000115f9 00160102 > ffc00186a0b0: 3e11

Re: [Crash-utility] ARM64 (odroid-c2) crash fails to read live kernel

- Original Message - > I have the new Odroid-C2 arm64 cortex-a53 board and have been trying to get > crash to work against the live kernel. > > I think the key error is this: > linux_banner: > crash: /lib/modules/3.14.29+/build/vmlinux and /dev/mem do not match! > > They should match

Re: [Crash-utility] makedumpfile: 4.5 kernel commit breaks page filtering

Laurence and Joe, Can you gents test Atsushi's fix in your environments? Thanks, Dave - Original Message - > Hello Dave, > > >>Note that PAGE_MAPPING_ANON is now only set in the compound_head page, > >>so when makedumpfile walks though the pages, it will have to look > >>at each

Re: [Crash-utility] 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

[Crash-utility] 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: [Crash-utility] crash-utility for inspecting FreeBSD VM dump

- Original Message - > > > Hi everyone, > > > > I am curious for inspecting FreeBSD VM dump by crash-utility. > > > > I built crash from source, and changed the configure option of gdb to target > FreeBSD. > > And used virsh dump --memory-only to generate freebsd.dump. > > But

Re: [Crash-utility] crash: invalid structure member offset with current kernels

- Original Message - > Hi, > > Crash fails to start with current (4.4+) kernels. The following patch > fixes this. > > Regards, > Sebastian Sebastian, Appreciate the heads-up -- queued for crash-7.1.5:

Re: [Crash-utility] 答复: 答复: failed to do crash analysis after insert custom module in the first kernel.

- Original Message - > Hi Dave: > > >From the kernel codes, I found the member in my kernel was changed to > >module_core_rx in CGL kernel, in crash's codes(6.1.4): kernel.c, there have > >the following content: > /**/ > case

Re: [Crash-utility] [BUG] ps -t pid

- Original Message - > Hi Dave, > > I just wanted to report a minor issue. > > The -t option on the 'ps' command will return invalid values for newer > kernels. > > I believe that this has to do with newer kernels around the 3.17 > timeframe having the 'start_time' field in the

Re: [Crash-utility] failed to do crash analysis after insert custom module in the first kernel.

- Original Message - > Hi Experts: > > Here is crash tool failed to work issue: > > 0, it occur on pwoerpc p2041(e500mc) board, p2020(e500v2) will not have this > issue. > kernel version: 2.6.34 > crash tool version: 6.1.4 That's a 3-year-old version of crash, you really should

Re: [Crash-utility] [BUG] ps -t pid

- Original Message - > Hi Dave, > > I just wanted to report a minor issue. > > The -t option on the 'ps' command will return invalid values for newer > kernels. > > I believe that this has to do with newer kernels around the 3.17 > timeframe having the 'start_time' field in the

Re: [Crash-utility] Extensions: Dump log buffer of Intel Processor Trace

- Original Message - > On 2016/01/06 12:32, Dave Anderson wrote: > > > > > > - Original Message - > >> On 2016/01/06 1:42, Dave Anderson wrote: > >>> > >>> > >>> - Original Message -

Re: [Crash-utility] Extensions: Dump log buffer of Intel Processor Trace

ode.c > ptdump-1.0.0/map.c > ptdump-1.0.0/map.h > ptdump-1.0.0/ptdump.c > ptdump-1.0.0/ptdump.mk > $ mv ptdump-1.0.0/* extensions > $ make extensions > gcc -Wall -g -nostartfiles -shared -rdynamic -o fastdecode.so fastdecode.c > -fPIC -DX86_64 -DLZO -DSNAPP

Re: [Crash-utility] [PATCH] arm64: support compat user mode prstatus

- Original Message - > (Somehow I wasn't on CC for your reply.) > > On Mon, Jan 04, 2016 at 04:14:51PM -0500, Dave Anderson wrote: > > > > > > - Original Message - > > > On Fri, Dec 18, 2015 at 11:55:07PM +0100, Andrew Jones wrote: >

Re: [Crash-utility] Extensions: Dump log buffer of Intel Processor Trace

- Original Message - > On 2016/01/06 1:42, Dave Anderson wrote: > > > > > > - Original Message - > >> > >> > >> - Original Message - > >>> Hi Dave, > >>> > >>> The attached files are ex

Re: [Crash-utility] Crash tool support for 3level-64k and 4level-4K page tables on ARM64

- Original Message - > Hi David, > > I recently tested makedumpfile on ARM64 with 3level-4K, 3level-64K and > 4level-4K page tables. > > I tried to analyze the dumpfile with the crash tool. > I noticed that with 3level-64K and 4level-4K I got the following error > when I tried to run

Re: [Crash-utility] [BUG} gdb disassembly-flavor affecting display of call stack.

- Original Message - > Hello, > > I've observed the following rather peculiar behavior of crash 7.1.3 (gdb > 7.6). > > crash> set 88000376d280 > PID: 9615 > COMMAND: "jbd2/dm-32-8" >TASK: 88000376d280 [THREAD_INFO: 880002bdc000] > CPU: 2 > STATE:

Re: [Crash-utility] [PATCH] x86_64: Fix that Particular kvaddr is converted to wrong paddr (RHEL6 x86_64)

meofday+12>: mov%rsi,%rbx > 0xff6f <vgettimeofday+15>: sub$0x8,%rsp > 0xff600013 <vgettimeofday+19>: test %rdi,%rdi > 0xff600016 <vgettimeofday+22>: je 0xff6000d5 > <vgettimeofday+213> > // abbreviation //

Re: [Crash-utility] [PATCH] sadump: two bugfixes relevant to zero excluded mode

>From f02ffc131933a8da8e516b2558c0945873ea290d Mon Sep 17 00:00:00 2001 From: HATAYAMA Daisuke Date: Fri, 18 Dec 2015 10:59:57 +0900 Subject: [PATCH 2/2] Switch to zero excluded mode by default on sadump-related formats. This is a fix for the regression, introduced by

Re: [Crash-utility] [PATCH] sadump: two bugfixes relevant to zero excluded mode

>From f02ffc131933a8da8e516b2558c0945873ea290d Mon Sep 17 00:00:00 2001 From: HATAYAMA Daisuke Date: Fri, 18 Dec 2015 10:59:57 +0900 Subject: [PATCH 2/2] Switch to zero excluded mode by default on sadump-related formats. This is a fix for the regression, introduced by

Re: [Crash-utility] arm64: bug report: segfault

Hi Drew, I am out of the office until Jan 4th, so I may not get around to checking this out fully until then. But in the meantime, can you save this dumpfile and send me a pointer to it offline? I want to keep it around for future testing. Thanks, Dave - Original Message - > Hi

[Crash-utility] [ANNOUNCE] crash version 7.1.4 is available

Download from: http://people.redhat.com/anderson or https://github.com/crash-utility/crash/releases The master branch serves as a development branch that will contain all patches that are queued for the next release: $ git clone git://github.com/crash-utility

<    2   3   4   5   6   7   8   9   10   11   >