Re: [Crash-utility] Can't read stack contents from qemu dump

- Original Message - > If you run "gdb vmlinux", does it find it? For example: > > (gdb) ptype union thread_union > Python Exception No module named gdb.types: > type = union thread_union { > struct task_struct task; > unsigned long stack[2048]; > } > (gdb) >

Re: [Crash-utility] Can't read stack contents from qemu dump

- Original Message - > > > On 4.04.2018 17:48, Dave Anderson wrote: > > > > > > - Original Message - > >> Hello, > >> > >> I tried running crash-head (HEAD: 5d172b230cf4) against today's linus' > >> mas

Re: [Crash-utility] Can't read stack contents from qemu dump

- Original Message - > Hello, > > I tried running crash-head (HEAD: 5d172b230cf4) against today's linus' > master on a dump obtained via dump-guest-memory in qemu. And I got the > following when the image is loaded: > > please wait... (determining panic task) > bt: read error: kernel

Re: [Crash-utility] [PATCH v4 0/6] Generalize KASLR calculation and use it for KDUMPs

Sergio, Takao and Daisuke, Thank you all for your efforts -- queued for crash-7.2.2: https://github.com/crash-utility/crash/commit/5d172b230cf46e7e1344b517746d868c9a8e2fd0 Dave - Original Message - > Commit 45b74b89530d611b3fa95a1041e158fbb865fa84 added support for > calculating

Re: [Crash-utility] [PATCH v3] vmware_vmss: read vCPUs regs and show them in 'bt'

- Original Message - > VMSS dump files contain the state of each vCPU at the time of suspending > the VM. This change enables 'crash' to read some relevant registers from > each vCPU state to display them in 'bt' and adds additional output for > commands 'help -D', 'help -r' and 'help

Re: [Crash-utility] [PATCH v2] vmware_vmss: read vCPUs regs and show them in 'bt'

- Original Message - > VMSS dump files contain the state of each vCPU at the time of suspending > the VM. This change enables 'crash' to read some relevant registers from > each vCPU state to display them in 'bt' and adds additional output for > commands 'help -D', 'help -r' and 'help

Re: [Crash-utility] [PATCH] vmware_vmss: read vCPUs regs and show them in 'bt'

- Original Message - > On Wed, Mar 21, 2018 at 10:44:47AM -0400, Dave Anderson wrote: > > > > > > - Original Message - > > > VMSS dump files contain the state of each vCPU at the time of suspending > > > the VM. This change enables 'cras

Re: [Crash-utility] [PATCH] vmware_vmss: read vCPUs regs and show them in 'bt'

- Original Message - > VMSS dump files contain the state of each vCPU at the time of suspending > the VM. This change enables 'crash' to read some relevant registers from > each vCPU state and display them in 'bt'. That's very helpful. I'm not sure why VMware never did anything like

Re: [Crash-utility] [PATCH v3 0/4] Generalize KASLR calculation and use it for KDUMPs

Hi Sergio, (and Takao and Daisuke) This patch to map_cpus_to_prstatus_kdump_cmprs(): @@ -153,8 +154,13 @@ resize_note_pointers: dd->num_qemu_notes * sizeof(void *))) == NULL) error(FATAL,

Re: [Crash-utility] [PATCH v2 0/4] Generalize KASLR calculation and use it for KDUMPs

- Original Message - > On Fri, Mar 16, 2018 at 04:33:41PM -0400, Dave Anderson wrote: > > > > Hi Sergio, > > > > A few initial comments/questions/concerns about this patch... > > > > > diff --git a/diskdump.c b/diskdump.c > > > i

Re: [Crash-utility] modules loaded from wrong directory

- Original Message - > When trying to run crash 7.2 like this, the 'mod -s $mod' command loads > the modules from the running system instead of the specified directory: > > d=${0%/*} > tee $t <<_EOF_ > mod -s xen-kbdfront > mod -s xen_kbdfront > exit > _EOF_ > > strace -f -s 123 -tt -o

Re: [Crash-utility] [PATCH 0/2] Generalize KASLR calculation and use it for KDUMPs

- Original Message - > > Hi Sergio, > > I have one obvious question. Throughout the patch-set you are using > KDUMP_DUMPFILE() as a qualifier, which is restricted to ELF vmcores > only. While the use of ELF vmcores is an option, it's far more likely > that the output format of "virsh

Re: [Crash-utility] [PATCH 0/2] Generalize KASLR calculation and use it for KDUMPs

Hi Sergio, I have one obvious question. Throughout the patch-set you are using KDUMP_DUMPFILE() as a qualifier, which is restricted to ELF vmcores only. While the use of ELF vmcores is an option, it's far more likely that the output format of "virsh dump --memory-only" will utilize one of the

Re: [Crash-utility] [PATCH v3 0/2] Fix KASLR problem on sadump

- Original Message - > Hi, > > I know support for guessing the KASLR offset for kdump/diskimages was > deliberately dropped from this patchset, because upstream was also working on > the vmcoreinfo device, but I think having that would be *really* useful. > > The vmcoreinfo device

Re: [Crash-utility] [PATCH v3] Speed up "kmem -[sS]" by optimizing is_page_ptr() for x86_64

Hi Kazuhito, Looks good -- queued for crash-7.2.2: https://github.com/crash-utility/crash/commit/4141373d9de3fea29f5d2b58f60e44bc132726c0 Thanks, Dave - Original Message - > changes v2 -> v3: > - move the setting point of machdep->is_page_ptr to machdep_init(SETUP_ENV) >

Re: [Crash-utility] [PATCH] Speed up "kmem -[sS]" by optimizing is_page_ptr()

Hi Kazuhito, The first step in the optimization of is_page_ptr() is checked in: https://github.com/crash-utility/crash/commit/d586679b861fafc99e96c863105826d30de630a7 Thanks, Dave - Original Message - > Hi Dave, > > On 2/27/2018 4:45 PM, Kazuhito Hagio wrote: > [...] > >> First,

Re: [Crash-utility] [PATCH] Speed up "kmem -[sS]" by optimizing is_page_ptr()

- Original Message - > Hi Dave, > > On 2/27/2018 4:45 PM, Kazuhito Hagio wrote: > [...] > >> First, the mem_section numbers are ascending. They may not necessarily > >> start > >> with 0, and there may be holes, but they are ascending. That being the > >> case, > >> there is no need

Re: [Crash-utility] [PATCH] ps: Introduce -A option

Hi Aaron. Cool! Queued for crash-7.2.2: https://github.com/crash-utility/crash/commit/6de5d2c034a8977e5b2be8ae1b48c4b6754a2684 Thanks, Dave - Original Message - > Show only details for the active task on each cpu: > >PIDPPID CPU TASKST %MEM VSZ

Re: [Crash-utility] [PATCH] filesys: Skip 'vmlinux.o' while searching for vmlinux in 'find_booted_kernel()'

Thanks Bhupesh -- the fix is queued for crash-7.2.2: https://github.com/crash-utility/crash/commit/a002f07040972a3d4b0743811e643bfba7b8cc99 Dave - Original Message - > Hi Dave, > > On Wed, Feb 28, 2018 at 9:09 PM, Dave Anderson <ander...@redhat.com> wrote: >

Re: [Crash-utility] [PATCH] filesys: Skip 'vmlinux.o' while searching for vmlinux in 'find_booted_kernel()'

Hi Bhupesh, Try this patch: $ diff --git a/filesys.c b/filesys.c index 1b44ad5..74728f1 --- a/filesys.c +++ b/filesys.c @@ -625,7 +625,7 @@ find_booted_kernel(void) if (mount_point(kernel) || !file_readable(kernel) || -

Re: [Crash-utility] [PATCH] filesys: Skip 'vmlinux.o' while searching for vmlinux in 'find_booted_kernel()'

Hi Bhupesh, Thanks -- mystery solved! I kind of hate to simply use the file name string as the qualifier, though. Looking at the ELF headers of the vmlinux.o and vmlinux file, there are several notable differences: $ readelf -a vmlinux ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00

Re: [Crash-utility] [PATCH] crash/symbols: Error out earlier in case _stext_vmlinux is NULL or UNINITIALIZED

Hi Bhupesh, I'm confused. If the vmlinux cannot be found, then the crash session should bail out after printing the standard error message in find_booted_kernel(): error(INFO, "cannot find booted kernel -- please enter namelist argument\n\n"); If derive_kaslr_offset() is

Re: [Crash-utility] [PATCH] Speed up "kmem -[sS]" by optimizing is_page_ptr()

- Original Message - > Hi Dave, > > On 2/21/2018 4:14 PM, Dave Anderson wrote: > > > > > > - Original Message - > >> Hi Dave, > >> > >> Thank you so much for your review! > >> > >> On 2/21/2018

Re: [Crash-utility] linux_banner has garbage

U 57: 268.75 secs > CPU 43: 268.75 secs > CPU 20: 268.75 secs > CPU 7: 268.75 secs > > crash> > I'm struggling to find out why my VM hung(unresponsive to ping/ssh and couple > of CPUs at 100% utilization). > > -Eshak > > On Thu, Feb 22, 2018 at 6:27 AM, Dav

Re: [Crash-utility] linux_banner has garbage

- Original Message - > Hello Dave, > > I got a kernel freeze yesterday and am able to successfully open the memory > image using crash utility. > > crash> sys > KERNEL: ./usr/lib/debug/usr/lib/modules/4.14.19-coreos/vmlinux > DUMPFILE: gt-Server02-gmt-612746ca.vmss >

Re: [Crash-utility] [PATCH] Speed up "kmem -[sS]" by optimizing is_page_ptr()

- Original Message - > Hi Dave, > > Thank you so much for your review! > > On 2/21/2018 11:41 AM, Dave Anderson wrote: > > > > Hi Kasuhito, > > > > Just as a follow-up review of this part of your original patch: > > > &g

Re: [Crash-utility] [PATCH] Speed up "kmem -[sS]" by optimizing is_page_ptr()

Hi Kasuhito, Just as a follow-up review of this part of your original patch: +#ifdef VMEMMAP_VADDR + nr = nr_mem_sections; + if (machdep->flags & VMEMMAP) + nr = pfn_to_section_nr((addr - VMEMMAP_VADDR) / SIZE(page)); +

Re: [Crash-utility] [PATCH] Speed up "kmem -[sS]" by optimizing is_page_ptr()

- Original Message - > Hi Dave, > > On 2/20/2018 11:32 AM, Dave Anderson wrote: > ... > >>>>> Another suggestion/question -- if is_page_ptr() is called with a NULL > >>>>> phys > >>>>> argument (as is done most of the tim

Re: [Crash-utility] [PATCH] Speed up "kmem -[sS]" by optimizing is_page_ptr()

- Original Message - > Hi Dave, > > On 2/16/2018 4:18 PM, Dave Anderson wrote: > ... > >>>> OK, I understand your point. But what concerns me is that the > >>>> function's > >>>> purpose is to absolutely identify whether the i

Re: [Crash-utility] [PATCH] Speed up "kmem -[sS]" by optimizing is_page_ptr()

- Original Message - > Hi Dave, > > On 2/15/2018 12:38 PM, Dave Anderson wrote: > ... > >>>> Because of your questions about ppc64, possible backwards-compatibility > >>>> issues, > >>>> or potential

Re: [Crash-utility] [PATCH] arm64: fix page size calculation

- Original Message - > As for v4.16-rc1, crash for arm64 fails to analyze the core dump, > with a message: cannot determine page size. > > There seems to be a couple of reasons for this: > [1] splits a 64-bit field of image header, _kernel_flags_le, into two > 32-bit values and in turn

Re: [Crash-utility] [PATCH] Speed up "kmem -[sS]" by optimizing is_page_ptr()

- Original Message - > > > - Original Message - > > Hi Dave, > > > > Thank you for your comment! > > > > On 2/13/2018 2:33 PM, Dave Anderson wrote: > > > > > > Hi Kasuhito, > > > > > > I am plann

Re: [Crash-utility] [PATCH] Speed up "kmem -[sS]" by optimizing is_page_ptr()

- Original Message - > Hi Dave, > > Thank you for your comment! > > On 2/13/2018 2:33 PM, Dave Anderson wrote: > > > > Hi Kasuhito, > > > > I am planning on releasing crash-7.2.1 today, so this will have to be > > deferred > >

[Crash-utility] [ANNOUNCE] crash version 7.2.1 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] Speed up "kmem -[sS]" by optimizing is_page_ptr()

Hi Kasuhito, I am planning on releasing crash-7.2.1 today, so this will have to be deferred to 7.2.2. Because of your questions about ppc64, possible backwards-compatibility issues, or potential future changes to page.flags usage, this permanent change to the is_page_ptr() function solely for

Re: [Crash-utility] linux_banner has garbage

t since phys_base defaults to 0, the --machdep argument wouldn't be necessary. Dave Thank you,Eshak On Wed, Feb 7, 2018 at 10:49 AM, Dave Anderson <ander...@redhat.com> wrote: - Original Message - > Hi Dave, > > Thanks for the info. > I've installed 7.2.

Re: [Crash-utility] linux_banner has garbage

info I can get from the vmem/vmss file like processes > running at the time or task blocked on I/O or anything ? > > Thank you, > Eshak > > On Wed, Feb 7, 2018 at 6:28 AM, Dave Anderson < ander...@redhat.com > wrote: > > > > > - Original Message

Re: [Crash-utility] linux_banner has garbage

]: patching 69420 gdb minimal_symbol values > > > > > crash: cannot resolve "init_level4_pgt" > > > > > [root@gt-Server2-gmt proc]# > But I believe this is fixed in crash 7.2. I have raised one issue against > CoreOS to make crash 7.2 to be available in t

Re: [Crash-utility] linux_banner has garbage

in crash 7.2. I have raised one issue against CoreOS to make crash 7.2 to be available in toolbox packages(https://github.com/coreos/bugs/issues/2347). Meanwhile, Is there any workaround for this ? -Eshak On Tue, Feb 6, 2018 at 6:02 PM, anderson <ander...@prospeed.net> wrote: To run

Re: [Crash-utility] linux_banner has garbage

26/gt-Server2-gmt-612746ca.vmss do not match!Usage:crash [OPTION]... NAMELIST MEMORY-IMAGE[@ADDRESS] (dumpfile form)  crash [OPTION]... [NAMELIST] (live system form)Enter "crash -h" for details.  [root@gt-Server2-gmt user]# Please let me know if you need any further information.Wi

Re: [Crash-utility] linux_banner has garbage

- Original Message - > Hello, > > We have a CoreOS VM(46 vCPU, 60GB RAM) freeze issue and hoping to find out > what is going on in it at the time of freeze. When the VM froze, we have no > access to it via ssh and ping works sometimes but not always. So, we > suspended the VM which

Re: [Crash-utility] [PATCH v2 2/2] fix error crash: cannot resolve "schedulers"

Nikola, Looks good -- patches are queued for crash-7.2.1: https://github.com/crash-utility/crash/commit/e4499a9de664826b0db2f650684959c2f3f9998c Thanks, Dave - Original Message - > Since Xen commit 666aca08175b ("sched: use the auto-generated list of > schedulers") crash

Re: [Crash-utility] [PATCH] Extend Xen hypervisor direct mapping on x86_64

Thanks Petr, queued for crash-7.2.1: https://github.com/crash-utility/crash/commit/e9ae5eb9749a62060610dc29d1b282bc79d3 Dave - Original Message - > Xen commit 615588563e99a23aaf37037c3fee0c413b051f4d (Xen 4.0.0.) > extended the direct mapping to 5 TB. This area was previously

Re: [Crash-utility] [PATCH] fix error crash: cannot resolve "schedulers"

- Original Message - > Dave Anderson <ander...@redhat.com> writes: > > > - Original Message - > >> Since Xen commit 666aca08175b ("sched: use the auto-generated list of > >> schedulers") crash cannot open Xen vmcores, because sy

Re: [Crash-utility] [PATCH] fix error crash: cannot resolve "schedulers"

- Original Message - > Since Xen commit 666aca08175b ("sched: use the auto-generated list of > schedulers") crash cannot open Xen vmcores, because symbol 'schedulers' > does not exits. Xen 4.7 implemented schedulers as its own section. > > xen/arch/x86/xen.lds.S >

Re: [Crash-utility] [PATCH v3 0/6] Second phase of future support for x86_64 5-level page tables

- Original Message - > Hi Dave, > > At 01/31/2018 03:49 AM, Dave Anderson wrote: > > > > Hello Dou, > > > > I have reviewed this second phase patchset, and have successfully tested it > > on > > existing kernels. I must say that it

Re: [Crash-utility] [PATCH v3 0/6] Second phase of future support for x86_64 5-level page tables

Hello Dou, I have reviewed this second phase patchset, and have successfully tested it on existing kernels. I must say that it is *very* well done -- I truly appreciate the effort that you have undertaken. The only thing I added was a reference to the "--machdep vm=5level" command line option

Re: [Crash-utility] [PATCH v2 0/6] Second phase of future support for x86_64 5-level page tables

- Original Message - > Hi Dave, > > At 01/13/2018 04:56 AM, Dave Anderson wrote: > > > > Hi Dou, > > > > This v2 version tests OK on my sample set of dumpfiles. I didn't > > get a chance to fully review the patchset, and I will be out of the &

Re: [Crash-utility] [PATCH] sadump: Fix a problem of PTI enabled kernel

- Original Message - > This patch fixes a problem that a dumpfile of sadump cannot be opened > by crash when Page Table Isolation(PTI) is enabled. > > When PTI is enabled, bit 12 of CR3 register is used to split user > space and kernel space. Also bit 11:0 is used for Process Context >

Re: [Crash-utility] Crash debugging vmcore, start error problem, crash seek error: kernel virtual address: fffffffffffffffa0 type: "kmem_cache buffer"

- Original Message - > > hi: > There is a problem that has been bothering me for several days. On the x86_64 > platform, I used crash to debug the vmcore file, but the crash cannot be > started normally during startup, and the error is as follows: > > # crash vmlinux vmcore > > please

Re: [Crash-utility] Using crash with structure layout randomized kernel

- Original Message - > ... > The 1st error is from reading "init_uts_ns"(randomized) value in > kernel_init, so kt->kernel_version is wrong, then results invalid > virtual addresses in "case POST_GDB:" of x86_64_init, the symptom of > this error is segment fault results from infinite

Re: [Crash-utility] Using crash with structure layout randomized kernel

- Original Message - > > > On 01/23/2018 11:19 PM, Dave Anderson wrote: > > > > > > - Original Message - > >> Hi Dave, > >> > >>     Recently I was trying crash tool with kdump dumpfile & structure > >> layo

Re: [Crash-utility] Using crash with structure layout randomized kernel

- Original Message - > Hi Dave, > >     Recently I was trying crash tool with kdump dumpfile & structure > layout randomized kernel[*](), and it fails without any surprise. After > looking into the different errors crash reports, I can confirm it is a > result from randomized structure

Re: [Crash-utility] [PATCH v2 0/6] Second phase of future support for x86_64 5-level page tables

- Original Message - > Hi Dave, > > At 01/13/2018 04:56 AM, Dave Anderson wrote: > > > > Hi Dou, > > > > This v2 version tests OK on my sample set of dumpfiles. I didn't > > get a chance to fully review the patchset, and I will be out of the &

Re: [Crash-utility] [PATCH v2 0/6] Second phase of future support for x86_64 5-level page tables

Hi Dou, This v2 version tests OK on my sample set of dumpfiles. I didn't get a chance to fully review the patchset, and I will be out of the office until next Tuesday. I'll try to review the patches then. Thanks very much, Dave - Original Message - > Changelog: > V1-->V2: >

Re: [Crash-utility] [PATCH 1/5] defs.h: Fix the PHYSICAL_PAGE_MASK macro

- Original Message - > Original crash defines the PHYSICAL_PAGE_MASK as > > (~(PAGE_SIZE-1) & (__PHYSICAL_MASK << PAGE_SHIFT)) > > It moves left PAGE_SHIFT bits for safety, But As crash expands the physical > bits to 52, this will cause the conversion of phythcal address to virtual >

Re: [Crash-utility] [PATCH 0/5] Second phase of future support for x86_64 5-level page tables

- Original Message - > I found Dave had alread done the first phase of future support for x86_64 > 5-level page tables(commit 307e7f35f510). when I asked him about the > state of this work, he gave me a more detailed answer and suggestion. > I follow his advice, and do the following job.

Re: [Crash-utility] Fail to parse dump of linux4.4 on arm64

- Original Message - > > when I use the crash tool to analysis the ram dump of linux4.4 on arm64,it > failed，is someone can help me？the error information as follow。 > > Port_COM151$ crash64 vmlinux >

Re: [Crash-utility] Question about extension modules

- Original Message - > Hello Dave, > > Several weeks ago there was a bugzilla report about crash-trace-command > which was caused by load_module structure change: > https://bugzilla.redhat.com/show_bug.cgi?id=1520825 > > We can solve the problem by updating crash-trace-cmd with the

Re: [Crash-utility] crash-utility parse ramdump of arm64 failed

- Original Message - > when I use the crash tool to analysis the ram dump of arm64,it failed，is > someone can help me？the error information as follow。 > > Port_COM151$ crash64 vmlinux >

Re: [Crash-utility] [PATCH] defs.h: Refine the FILL_PML4() macro

Queued for crash-7.2.1: https://github.com/crash-utility/crash/commit/3fe2663be5c6a5b160025a5a65b655a570e7e79e Thanks, Dave - Original Message - > The FILL_PML4() updates the machdep->machspec->last_pml4_read every time. > > But the last_pml4_read only need to be updated when

Re: [Crash-utility] Why does crash check the program context flags in FILL_PML4() macro

- Original Message - > Hi Dave, > > One question: > > #define FILL_PML4() { \ > if (!(pc->flags & RUNTIME) || ACTIVE()) { \ > ^ > I am confused that crash checks the flags in the FILL_PML4() macro, but > not check that in other

Re: [Crash-utility] [RFC PATCH] defs.h: Update the range of legacy vsyscall to 4kB

Queued for crash-7.2.1: https://github.com/crash-utility/crash/commit/cff3f2076ab52b9d6bae2b516fe3de32cccdb830 Thanks, Dave - Original Message - > Currently, There used to be 8 MB reserved for future vsyscalls, but > that's long gone in Kernel. and it updates to 4kB > > So

Re: [Crash-utility] [PATCH] defs.h: Update the vmalloc start address of 5-Level

Queued for crash-7.2.1: https://github.com/crash-utility/crash/commit/b6c0fc74fa58d48a0b6801de790e86db1130d22f Thanks, Dave - Original Message - > Due to the support of PTI in Kernel, the range of Virtual memory map with > 5 level page tables [ff90 -

Re: [Crash-utility] Fw: [CentOS] Can't see register value in crash vmcore

Sent from my Verizon, Samsung Galaxy smartphone Original message From: wuzhouhui Date: 12/29/17 2:34 AM (GMT-05:00) To: crash-utility@redhat.com Subject: [Crash-utility] Fw: [CentOS] Can't see register value in crash vmcore

Re: [Crash-utility] How to specify symbol if they have same name

Use the relevant virtual address as the argument. Dave Sent from my Verizon, Samsung Galaxy smartphone Original message From: wuzhouhui Date: 12/28/17 6:33 PM (GMT-05:00) To: crash-utility@redhat.com Subject: [Crash-utility] How to specify

Re: [Crash-utility] What is the current state of the 5-level page tables in Crash

- Original Message - > Hi Dave, > > At 12/20/2017 02:15 AM, Dave Anderson wrote: > > > > > > - Original Message - > >> Dear Dave, > >> > >> I saw your commit > >> > >> 307e7f35f510("First phase of

Re: [Crash-utility] What is the current state of the 5-level page tables in Crash

- Original Message - > Dear Dave, > > I saw your commit > > 307e7f35f510("First phase of future support for x86_64 5-level page > tables.") > > in crash git-tree. It is the preparatory for x86_64 5-level page tables. > There may be more things to be done to support for 5-level.

Re: [Crash-utility] [PATCH] ppc64: fix bt for secondary threads for NMI IPIs

- Original Message - > With latest NMI IPI changes, crash_ipi_callback is found multiple times > on the stack. Ensure the chosen symbol relates to an actual backtrace. Looks good -- queued for crash-7.2.1:

Re: [Crash-utility] [PATCH v2] Fix a segfault by "net" command

- Original Message - > Hi Dave, > > I updated my patch to fix a lack of the function's return value. > Hi Kazuhito, Thanks for the v2 update -- queued for crash-7.2.1: https://github.com/crash-utility/crash/commit/a94b86e9eb3faa963a7c20517574d230837a4292 Dave > -- > When a

Re: [Crash-utility] crash: page excluded: kernel virtual address: ffffffff81e3da50 type: "page_offset_base"

- Original Message - ... [ cut ] ... > BTW, I think the fedora version crash tool should works well with fedora > kernel? But in my test, crash 7.1.9.3 & 4.13.13-300.fc27.x86_64, crash > report: > >   crash: cannot resolve "init_level4_pgt" > > which is said is solved in crash 7.2.0

Re: [Crash-utility] crash: page excluded: kernel virtual address: ffffffff81e3da50 type: "page_offset_base"

- Original Message - > Hi Dave, > > Information update: I think I found the root cause. > > During the test in last week, I always use makedumpfile, use > /etc/kdump.conf as-is: > >     core_collector makedumpfile -l --message-level 1 -d 31 > > And now I am suggested to dump without

Re: [Crash-utility] crash: page excluded: kernel virtual address: ffffffff81e3da50 type: "page_offset_base"

Jie/费 杰 wrote: >> >> >> >> Forwarded Message >> Subject: Re: [Crash-utility] crash: page excluded: kernel virtual >> address: 81e3da50 type: "page_offset_base" >> Date:Wed, 22 Nov 2017 09:35:40 -0500 >> From:D

Re: [Crash-utility] [PATCH] Fix a segfault by "net" command

- Original Message - > > > - Original Message - > > Hi Dave, > > > > When a network device has a lot of IP addresses, the "net" command > > can generate a segmentation fault due to a buffer overflow without > > this patch. I have seen several vmcores like that in customer

Re: [Crash-utility] [PATCH] Fix a segfault by "net" command

- Original Message - > Hi Dave, > > When a network device has a lot of IP addresses, the "net" command > can generate a segmentation fault due to a buffer overflow without > this patch. I have seen several vmcores like that in customer support. Thanks, Kasuhito -- I will give the

Re: [Crash-utility] HEADS UP: upstream kernel pidhash removal

- Original Message - > > FYI, if you're running with bleeding edge upstream kernels, this > recent commit destroys a fundamental underpinning required by the > crash utility: > > commit e8cfbc245e24887e3c30235f71e9e9405e0cfc39 > Author: Gargi Sharma > Date:

Re: [Crash-utility] crash: page excluded: kernel virtual address: ffffffff81e3da50 type: "page_offset_base"

- Original Message - > Hi, > > I am using the latest crash tool & kernel 4.14 compiled from source, and > I got the following error message. As I searched, this is fixed in crash > 7.2.0, but I still have it here. So, is anyone has a clue? It's always going to be a crap-shoot with very

[Crash-utility] HEADS UP: upstream kernel pidhash removal

FYI, if you're running with bleeding edge upstream kernels, this recent commit destroys a fundamental underpinning required by the crash utility: commit e8cfbc245e24887e3c30235f71e9e9405e0cfc39 Author: Gargi Sharma Date: Fri Nov 17 15:30:34 2017 -0800 pid:

Re: [Crash-utility] [PATCH RFCv1] Crash: Extensions: Coresight panic dump

ash package: > > > --- > > extensions/csdump.c | 547 > > > > 1 file changed, 547 insertions(+) > > create mode 100644 extensions/csdump.c > > Can you please create a simple standalone package that can be a

Re: [Crash-utility] [PATCH RFCv1] Crash: Extensions: Coresight panic dump

.c Can you please create a simple standalone package that can be added to the extensions page here: http://people.redhat.com/anderson/extensions.html When your standalone pacakge is ready, I will add it to that page. And any future updates to the package can be posted there as a new revision wheneve

Re: [Crash-utility] [PATCH v2 0/1] Display relative lag of each CPU

- Original Message - > While analyzing vmcore it is useful to have an information > about relative lag of each CPU. Usually, people do something like this: > > runq -t | grep CPU | sort -k3r | > awk 'NR==1{now=strtonum("0x"$3)}1{printf"%s\t%7.2fs behind\n", >

Re: [Crash-utility] [PATCH v2] book3s/ppc64: update hash page table geometry

Yep, I noticed that too late.  I'll change it to 4.12 in the crash.changelog file when I release 7.2.1. Sent from my Verizon, Samsung Galaxy smartphone Original message From: Hari Bathini <hbath...@linux.vnet.ibm.com> Date: 11/9/17 12:14 PM (GMT-05:00) To: Dave An

Re: [Crash-utility] [PATCH v2] book3s/ppc64: update hash page table geometry

- Original Message - > Starting with kernel 4.12, the hash page table geometry is updated to > accommodate larger VA range. Update here accordingly. > > Signed-off-by: Hari Bathini > --- > changes in v1: > * Kernel commit 92d9dfda8b54 reverted the geometry

Re: [Crash-utility] [PATCH RFC 0/1] Display relative lag of each CPU

submission. > > On Wed, Nov 8, 2017 at 5:33 PM, Dave Anderson <ander...@redhat.com> wrote: > > > > > > - Original Message - > >> While analyzing vmcore it is useful to have an information > >> about relative lag of each CPU. Usually, people do so

Re: [Crash-utility] [PATCH RFC 0/1] Display relative lag of each CPU

- Original Message - > While analyzing vmcore it is useful to have an information > about relative lag of each CPU. Usually, people do something like this: > > runq -t | grep CPU | sort -k3r | > awk 'NR==1{now=strtonum("0x"$3)}1{printf"%s\t%7.2fs behind\n", >

Re: [Crash-utility] [PATCH v2 0/1] Add option to filter disks with no I/O in progress

- Original Message - > While analyzing vmcores the first thing that people do when they want > to check disk I/O is something like this: > > crash> dev -d | awk '$5 != 0' > > Since there might be lots of disks, this makes scrolling through them > much easier. > > I think we should

Re: [Crash-utility] [PATCH] fix vmstat handling (4.11 swap cache changes)

- Original Message - > Hi Dave, > > On Fri, Nov 3, 2017 at 11:32 PM, Dave Anderson <ander...@redhat.com> wrote: > > > > > > - Original Message - > >> On Thu, Nov 2, 2017 at 8:58 PM, Dave Anderson <ander...@redhat.com> wr

Re: [Crash-utility] [PATCH] fix vmstat handling

PM, Dave Anderson <ander...@redhat.com> wrote: > > > > > > - Original Message - > >> On Thu, Nov 2, 2017 at 8:58 PM, Dave Anderson <ander...@redhat.com> wrote: > >> > > >> > > >> > - Original Message - > >

Re: [Crash-utility] [PATCH] fix vmstat handling

- Original Message - > On Thu, Nov 2, 2017 at 8:58 PM, Dave Anderson <ander...@redhat.com> wrote: > > > > > > - Original Message - > >> From: Vinayak Menon <vinayakm.l...@gmail.com> > >> > >> With kernels where LRU

Re: [Crash-utility] [PATCH] fix "ps -l"

Hi Vinayak, Thanks for catching that, a regression caused by the new "ps -y" patch. Queued for crash-7.2.1: https://github.com/crash-utility/crash/commit/f852f5ce4d28f88308f0e555c067e63e3edd7f37 Dave - Original Message - > fix segfault when executing "ps -l". > >

Re: [Crash-utility] [PATCH] fix vmstat handling

- Original Message - > From: Vinayak Menon > > With kernels where LRUs are moved to node and thus vm_stat is > split into zone and node, crash utility fails to show the vmstat with "kmem > -V", and the "CACHED" of kmem -i is shown as zero. > > Signed-off-by:

Re: [Crash-utility] [PATCH RFC 00/14] Minor code cleanups, round zero

- Original Message - > Hi, Dave. > > Thanks for your intensive review and accepting contribution. > > Nevertheless, I'd appreciate if you explicitly comment on the following > series: > > lkcd_v8: address of an array always evaluates to true > lkcd_v7: address of an array always

Re: [Crash-utility] [PATCH RFC 0/1] Add an ability to filter timers by CPUs

- Original Message - > Sometimes it is pretty handy to filter timer list by CPUs, > especially if vmcore was captured on a machine with many cores. > Grepping "timer" command output is too cumbersome, so let's add > extra -C switch to it. > > Initially, idea belongs to Aaron Tomlin (in

Re: [Crash-utility] [PATCH RFC 00/14] Minor code cleanups, round zero

- Original Message - > Hi, Dave, Daisuke. > > > OK, mystery solved. > > … > > Regardless, I fixed the patch to be based upon the kernel version, and > > queued > > it for crash-7.1.2: > > > > > > https://github.com/crash-utility/crash/commit/e81db08bc69fb1a7a7e48f892c2038d992a71f6d >

Re: [Crash-utility] [PATCH RFC 02/14] memory: do not compare unsigned expression with negative value

- Original Message - > Signed-off-by: Oleksandr Natalenko > --- > memory.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/memory.c b/memory.c > index 9926199..abf3982 100644 > --- a/memory.c > +++ b/memory.c > @@ -14467,7 +14467,7 @@

Re: [Crash-utility] [PATCH RFC 12/14] sadump: block_size is always non-negative

- Original Message - > > ... [ cut ] ... > > > > And I'm not sure whether this one should be fixed by just removing the > > statement: > > > > --- a/sadump.c > > +++ b/sadump.c > > @@ -157,9 +157,6 @@ read_dump_header(char *file) > > } > > > > restart: > > -if

Re: [Crash-utility] [PATCH RFC 05/14] x86_64: clarify logical operator precedence

A fix has been queued for crash-7.2.1: https://github.com/crash-utility/crash/commit/0f40db8fbac538ea448bbb2beb44912e4c43a54a Thanks, Dave - Original Message - > Signed-off-by: Oleksandr Natalenko > --- > x86_64.c | 4 ++-- > 1 file changed, 2

Re: [Crash-utility] [PATCH RFC 02/14] memory: do not compare unsigned expression with negative value

- Original Message - > Signed-off-by: Oleksandr Natalenko > --- > memory.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/memory.c b/memory.c > index 9926199..abf3982 100644 > --- a/memory.c > +++ b/memory.c > @@ -14467,7 +14467,7 @@

Re: [Crash-utility] [PATCH RFC 00/14] Minor code cleanups, round zero

- Original Message - > > > - Original Message - > > - Original Message - > > > > > > I'll take a look at these when I get the chance, but I'm really > > > not particularly excited unless they are actual bugs. > > > > Like this one: > > > > --- a/memory.c > > +++

Re: [Crash-utility] [PATCH RFC 00/14] Minor code cleanups, round zero

- Original Message - > - Original Message - > > > > I'll take a look at these when I get the chance, but I'm really > > not particularly excited unless they are actual bugs. > > Like this one: > > --- a/memory.c > +++ b/memory.c > @@ -17003,8 +17003,8 @@ valid_section(ulong

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