- Original Message -
> Fix for the "kmem -i" option on Linux 5.0 and later kernels that
> contain commit ca79b0c211af63fa3276f0e3fd7dd9ada2439839, titled
> "mm: convert totalram_pages and totalhigh_pages variables to atomic".
> Without the patch, the command prints some incorrect values,
Thanks Kazu -- queued for crash-7.2.6:
https://github.com/crash-utility/crash/commit/84f5e2a19e89236aa559f3b0d5024f3001c75a06
Dave
- Original Message -
> Fix for the "kmem -z" command on Linux 5.0 and later kernels that
> contain commit a921444382b49cc7fdeca3fba3e278bc09484a27, ti
- Original Message -
>
>
> - Original Message -
> > We are using ELFXX_sym->st_info directly as the 'type' of symbol,
> > which is wrong, because st_info contains numeric value which needs
> > to be mapped to appropriate type character.
>
> I'm confused here. If I dump each m
- Original Message -
> We are using ELFXX_sym->st_info directly as the 'type' of symbol,
> which is wrong, because st_info contains numeric value which needs
> to be mapped to appropriate type character.
I'm confused here. If I dump each module symbol's st_info fields as they are
bein
- Original Message -
> ARM kernels built with the Thumb-2 instruction need R7 instead of FP for
> unwinding stacks using the DWARF unwinder.
>
> On a Thumb-2 kernel:
>
> Before:
> crash> bt 1
> PID: 1 TASK: ee7e CPU: 1 COMMAND: "systemd-shutdow"
>
> After:
> crash> bt 1
>
- Original Message -
> Hi Dave,
>
> When tring to debug a kernel core file generated from Debian 9.2 + 4.9 kernel
> with base address randomized (this core is create for a qemu vm), it gives
> the error as:
>
> WARNING: cannot determine physical base address: defaulting to 0
>
> GNU gd
- Original Message -
...
> >
> > It looks like the kernel patch was backported into Linux 4.14.84, so to
> > satisfy that
> > possibility, can you apply the attached patch to the upstream github
> > version of crash,
> > and see if it works? If it does, I'll apply it upstream in githu
- Original Message -
> On Tue, Feb 12, 2019 at 11:03 AM Dave Anderson wrote:
> >
> >
> >
> > - Original Message -
> > >
> > >
> > > - Original Message -
> > > > Hi,
> > > >
> > > >
nd __PAGE_OFFSET_BASE_L5 in
"arch/x86/include/asm/page_64_types.h".
If the 4.14.91 kernel has a backport of commit
d52888aa2753e3063a9d3a0c9f72f94aa9809c15
"x86/mm: Move LDT remap out of KASLR region on 5-level paging", then you'll need
the github version of crash, which
- Original Message -
> Hi,
>
> I'm running vanilla Linux 4.14.91 and I cannot seem to obtain a
> working crash dump file from any kernel panic. We've experienced
> several recently, and each has similar output to this below when
> attempting to use the 'crash' utility:
>
> --snip--
> c
Hello WANG,
I've applied a patch upstream that addresses the issue automatically
for 4.20 and later kernels, but requires a command line option for
kernels that contain a backport of kernel commit d52888aa2753. As
mentioned in the commit message, that requirement may be revisited
in the future
Hi Dietmar,
Your patches are queued for crash-7.2.6:
https://github.com/crash-utility/crash/commit/c6f0db666191df2342f536945f89cfcad88d265a
Thanks,
Dave
- Original Message -
> Hi Dave,
>
> when trying to debug the xen hypervisor on a vmcore file it doesn't work for
> me.
> xen_
- Original Message -
>
>
> > -Original Message-
> > - Original Message -
> > > I faced an incomplete vmcore previous week which was generated because
> > > system running in kdump kernel was somehow rebooted in the middle of
> > > copying vmcore.
> > >
> > > Unfortunate
- Original Message -
> commit d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on
> 5-level paging") changed PAGE_OFFSET from 0x8800 to
> 0x8880.
>
> crash can't open such with CONFIG_RANDOMIZE_BASE=n:
>
> crash: read error: kernel virtual address:
- Original Message -
> I faced an incomplete vmcore previous week which was generated because
> system running in kdump kernel was somehow rebooted in the middle of
> copying vmcore.
>
> Unfortunately, in the incomplete vmcore, most of the tasks failed to
> be detected via PID hash tabl
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
- Original Message -
> Fix for the "dev -d|-D" command on Linux 4.20 and later kernels.
> In Linux 4.20, in_flight member in struct request_queue is disappeared.
> And also struct request_list is removed. So, dev -d|-D doesn't work.
>
> Unfortunately, it seems that there is no alternati
--- a/memory_driver/crash.c
> +++ b/memory_driver/crash.c
> @@ -3,6 +3,7 @@
> *
> * Copyright (C) 2004, 2011, 2016 Dave Anderson
> * Copyright (C) 2004, 2011, 2016 Red Hat, Inc.
> + * Copyright (C) 2019 Serapheim Dimitropoulos
> */
>
>
> /***
- Original Message -
>
> > -Original Message-
> > From: Dave Anderson [mailto:ander...@redhat.com]
>
> > - Original Message -
> > > This is the release of crash gcore command, version 1.5.0.
> > >
> > > The aim o
- Original Message -
> With kernel commit 4ffe713b7587 ("powerpc/mm: Increase the max addressable
> memory to 2PB"), MAX_PHYSMEM_BITS is bumped up to 51 for SPARSEMEM_VMEMMAP
> and SPARSEMEM_EXTREME case. Make the appropriate update here.
>
> Signed-off-by: Hari Bathini
Thanks Hari --
- Original Message -
> This is the release of crash gcore command, version 1.5.0.
>
> The aim of this release is mainly to support v4.18 and newer kernels.
>
> ChangeLog:
>
> - Fix the issue that special vmas such as vdso and vsyscall are not
> saved in a produced core file due
- Original Message -
> radix trees got replaced with xarrays in 4.20-rc1's f8d5d0cc145
> ("xarray: Add definition of struct xarray") and 01959dfe77 ("xarray:
> Define struct xa_node")
>
> Attempt to detect and support this.
> ---
> Dave A
- Original Message -
> Hi,
>
> just a head's up that the linux radix_tree got replaced by something
> called xarray in 4.20 (already into master, will be in 4.20-rc1)
>
> You can look at the patch series here:
> https://lore.kernel.org/lkml/20180313132639.17387-3-wi...@infradead.org/T/
- Original Message -
> On Tue, Oct 09, 2018 at 09:39:10AM -0400, Dave Anderson wrote:
> >
> >
> > - Original Message -
> > > On Mon, Oct 01, 2018 at 09:37:10AM -0400, Dave Anderson wrote:
> > > >
> > > >
> > > &
- Original Message -
> On Mon, Oct 01, 2018 at 09:37:10AM -0400, Dave Anderson wrote:
> >
> >
> > - Original Message -
> > > Implemented support for 16k stack size that was introduced by commit
> > > 6538b8ea886e472f4431db8ca1d6047
- Original Message -
> ...
>
> > It is nice macro! The macro returns machdep->pageshift and
> > it is stored at crash initialization in all arch, right?
> > So, does the following make sense?
>
> Yeah, that should be OK. It depends upon the architecture, but it looks
> like latest poi
- Original Message -
> On Fri, Oct 05, 2018 at 09:13:28AM -0400, Dave Anderson wrote:
> >
> >
> > - Original Message -
> > > On Thu, Oct 04, 2018 at 05:03:25PM -0400, Dave Anderson wrote:
> > > > - Original Message -
> >
- Original Message -
> On Thu, Oct 04, 2018 at 05:03:25PM -0400, Dave Anderson wrote:
> > - Original Message -
> ...
> > Actually I was too quick to check the patch in -- it fails to build on most
> > of the other architectures, like here on
- Original Message -
>
>
> - Original Message -
> > From: Masayoshi Mizuma
> >
> > Update for the "kmem -n" option to also dump memory block.
> > Currently, "kmem -n" shows the memory section only. This
> > patch gets available the memory block as well if 'memory_block'
> > st
- Original Message -
> From: Masayoshi Mizuma
>
> Update for the "kmem -n" option to also dump memory block.
> Currently, "kmem -n" shows the memory section only. This
> patch gets available the memory block as well if 'memory_block'
> structure and 'memory_subsys' symbol exist.
> The
- Original Message -
>
... [ cut ] ...
>
> How about the following layout? The following shows the sections
> which belong to the memory block.
>
> crash> kmem -n
> ...
> NR SECTIONCODED_MEM_MAPMEM_MAP STATE PFN
> 0 88047e5d6000 ea00
- Original Message -
> From: Masayoshi Mizuma
>
> Update for the "kmem -n" option to also dump memory block.
> Currently, "kmem -n" shows the memory section only. This
> patch gets available the memory block as well if 'memory_block'
> structure and 'memory_subsys' symbol exist.
> The
- Original Message -
>
> From: Hari Bathini
>
> Add PPC64 specific flag for kernels running on platforms based on
> OPAL firmware. Use this flag before processing commands specific to
> OPAL based systems.
Thanks Hari -- queued for crash-7.2.5:
https://github.com/crash-utility/cras
- Original Message -
> Implemented support for 16k stack size that was introduced by commit
> 6538b8ea886e472f4431db8ca1d60478f838d14b titled "x86_64: expand kernel
> stack to 16K".
> Without the patch, kernels has 16k stack, leading to errors in commands
> such as "bt" and any command r
- Original Message -
>
>
> - Original Message -
> >
> > On 9/27/2018 1:42 PM, Dave Anderson wrote:
> > >
> > >
> > > - Original Message -
> > >> Currently, when using pipe in command line, we ca
- Original Message -
>
> On 9/27/2018 1:42 PM, Dave Anderson wrote:
> >
> >
> > - Original Message -
> >> Currently, when using pipe in command line, we cannot specify
> >> a script with shebang directly like this:
> >>
&g
- Original Message -
> 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.
Thanks Hari, queued for crash-7.2.5:
https://github.com/crash-utility/c
- Original Message -
> Currently, when using pipe in command line, we cannot specify
> a script with shebang directly like this:
>
> crash> foreach bt | ./analyze.awk
> crash: pipe operation failed
>
> (or it looks like crash can loop until Ctrl-C depending on timing)
>
> This i
Hello Masayoshi,
Your patch has been queued for crash-7.2.5:
https://github.com/crash-utility/crash/commit/27a6ebd0cda386b1dfb7b0fffb4d8b489b391ccf
Note that I moved the new offset_table entries to the end of the structure so
that previously-compiled extension modules using OFFSET() will no
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
As an addendum to crash commit 5fe78861ea1589084f6a2956a6ff63677c9269e1,
this patch for the ppc64 "bt" command prevents an invalid error message
from being displayed when an active non-panic task is interrupted while
running in user space. Without the patch, the command correctly indicates
"Task
Hi Hari,
Can you check the original bugzilla w/respect to a task running
in user space when the crash occurs?
Thanks,
Dave
- Original Message -
>
>
> - Original Message -
> > Commit 3db3d3992d78 was aimed at making 'bt' work for dumpfiles saved
> > with fadump but it intro
- Original Message -
> Commit 3db3d3992d78 was aimed at making 'bt' work for dumpfiles saved
> with fadump but it introduced a bit of unwarranted complexity in 'bt'
> command processing. Rework 'bt' command processing for PPC64 arch to
> make it a little less compilated and also, print s
- Original Message -
>
> ... [ cut ] ...
>
> But then again, I note that "files -p" fails quite frequently due to
> some kind of mis-use of the contents of the radix tree. The 2 options
> were introduced together in crash-7.1.2, but I've never really used them.
>
FYI: I fixed do_radi
- Original Message -
> Since the kernel commit b93b016313b3ba8003c3b8bb71f569af91f19fc7
> ("page cache: use xa_lock") renamed the address_space ->page_tree
> to ->i_pages, without this patch, the "files -[cp]" options don't
> work on Linux 4.17 and later kernels.
> (In this case, is it O
- Original Message -
> kernels which have CONFIG_HAVE_ARCH_PREL32_RELOCATIONS will now store
> module symbol values relative to themselves since linux kernel's commit
> 7290d580957 ("module: use relative references for __ksymtab entries")
>
> Do the lookup one way or another depending o
Hi Kazu,
Nicely done -- queued for crash-7.2.4:
https://github.com/crash-utility/crash/commit/e541c5ca2766d6d6934f435955d70aa7b3fd52b0
Thanks,
Dave
- Original Message -
> On 8/23/2018 4:31 PM, Dave Anderson wrote:
> >
> >
> > - Original Message ---
- Original Message -
> Nowadays, the "kmem -s" output can become very long vertically too,
> due to the memcg kmem caches. It look like the longer a system has
> run, the longer it becomes.
>
> crash> kmem -s | wc -l
> 19855
>
> On the other hand, since /proc/slabinfo accumulates
- Original Message -
> With recent kernels without CONFIG_NUMA (including Fedora 32-bit),
> the vm_stat_init() function aborts when getting numa_stat_item
> enum items, (probably) because it is not defined.
>
> crash> kmem -V
> double free or corruption (!prev)
> Aborted (core dum
- Original Message -
> Fix the extension trace.so for RHEL7.6 ,which moved
> ftrace_event_call.data into an anonymous union,and the
> previous offset has changed, so the trace.so extension
> module fails to load ,indicating "no commands registered:
> shared object unloaded".
Thanks Xu -
Hi Xu,
That's good to hear. I see that you are already on the crash-utility mailing
list.
I tried to add your email address to this current rhel-7.6 bugzilla:
Bug 1596549 - [RHEL-7.6][crash-trace-cmd] Failed to extend trace.so: "no
commands registered: shared object unloaded"
https://
- Original Message -
>
> Hi Dave,
>
>
> On 8/8/2018 2:24 PM, Dave Anderson wrote:
> >
> > Kazu,
> >
> > Nicely done! It's a huge improvement in readability, cleans up some
> > unnecessary duplication, and tests well on all of my ol
- Original Message -
> Usually, structure fd_set only has 1024 bits size, when a process
> using large amount of file descriptors that exceed the size of fd_set,
> then the display of files and net sockets would mistake caused by the
> out of bounds reading in loop.
>
> Signed-off-by: T
Kazu,
Nicely done! It's a huge improvement in readability, cleans up some
unnecessary duplication, and tests well on all of my old and new
kernel dumpfiles that I have on hand. Queued for crash-7.2.4:
https://github.com/crash-utility/crash/commit/455da1ae5c7f22ba870aa57e071dad340749bdcd
T
Tan,
I will review your patch when I return from vacation next week.
Thanks,
Dave
- Original Message -
> Usually, structure fd_set only has 1024 bits size, when a process
> using large amount of file descriptors that exceed the size of fd_set,
> then the display of files and net soc
Hi Kazu,
I'll be back from vacation next week, and I'll take a look at the patch then.
Sounds like a reasonable idea, and I have plenty of "old" sample vmcores.
Thanks, Dave
Sent from my Verizon, Samsung Galaxy smartphone
Original message From: Kazuhito Hagio
Date: 7/30/18
Kazu,
The patch looks good and tests OK -- queued for crash-7.2.4:
https://github.com/crash-utility/crash/commit/a10917ba3203aa8b20e2aa1b84dc12c1e17445e1
Thanks,
Dave
- Original Message -
> kernel commit 06eb61844d ("sched/debug: Add explicit TASK_IDLE
> printing") exposed the TAS
- Original Message -
> There's no way to enable paging mode on per-task basis. So, Check
> for per-task is redundant. Remove the x86_64_task_uses_5level()
Beautiful -- queued for crash-7.2.4:
https://github.com/crash-utility/crash/commit/61fcad549faa479e6831d5283387f8f2e4ec9202
Tha
- Original Message -
> At 07/12/2018 09:08 PM, Dave Anderson wrote:
> >
> >
> > - Original Message -
> >>
> >>
> >> At 07/12/2018 02:23 AM, Dave Anderson wrote:
> >>>
> >>>
> >>> - Orig
- Original Message -
>
>
> At 07/12/2018 02:23 AM, Dave Anderson wrote:
> >
> >
> > - Original Message -
> >>
> >>
> >> - Original Message -
> >>> Hi Dave,
> >>>
> >>> At 0
Dave,
Just an awesome job man...
Queued for crash-7.2.4:
https://github.com/crash-utility/crash/commit/6596f1121b89162f96d1e1825c2905b83b59bec1
Thanks,
Dave
- Original Message -
> The list command by default uses a hash table for loop detection, and thus
> uses an increasing
- Original Message -
>
>
> - Original Message -
> > Hi Dave,
> >
> > At 07/11/2018 03:33 AM, Dave Anderson wrote:
> > >
> > > The final phase of support would be making this work:
> > >
> > >stat
- Original Message -
> Hi Dave,
>
> At 07/11/2018 03:33 AM, Dave Anderson wrote:
> >
> > The final phase of support would be making this work:
> >
> >static int
> >x86_64_task_uses_5level(struct task_context *tc)
> >{
> &
;
> >
> >
> >
> > - Original Message -
> > > Currently, Crash only enable support for kernel-only 5-level page tables
> > > by
> > > entering the command line option "--machdep vm=5level". Since Linux 4.17,
> > > t
or kernel-only 5-level page tables by
> > entering the command line option "--machdep vm=5level". Since Linux 4.17,
> > the Linux kernel can be both 4level and 5level page tables. This command
> > line
> > can't work well for this.
> >
> > Using the
Linux 4.17,
> the Linux kernel can be both 4level and 5level page tables. This command line
> can't work well for this.
>
> Using the "pgtable_l5_enabled" to detect whether the kernel proper for 5
> level
> page tables automatically. Also move the 5-level paging set
- Original Message -
> Dear Dave,
>
> At 07/06/2018 09:45 PM, Dave Anderson wrote:
> >
> >
> > - Original Message -
> >> Currently, Crash only enable support for kernel-only 5-level page tables by
> >> entering the command line o
- Original Message -
> Currently, Crash only enable support for kernel-only 5-level page tables by
> entering the command line option "--machdep vm=5level". Since Linux 4.17,
> the Linux kernel can be both 4level and 5level page tables. This command line
> can't work well for this.
>
>
Chris,
This list is for the crash utility (which doesn't care where the vmcore
dumpfile came from). For kdump-related questions, try the kexec mailing
list here:
http://lists.infradead.org/mailman/listinfo/kexec
Dave
- Original Message -
> Hi,
>
> Buried in this thread on the Bo
- Original Message -
> On Tue, 2018-06-26 at 11:59 -0400, Dave Anderson wrote:
> >
> > - Original Message -
> > > On Tue, 2018-06-26 at 11:27 -0400, Dave Anderson wrote:
> > > >
> > > > - Original Message -
> >
- Original Message -
> On Tue, 2018-06-26 at 11:59 -0400, Dave Anderson wrote:
> >
> > - Original Message -
> > > On Tue, 2018-06-26 at 11:27 -0400, Dave Anderson wrote:
> > > >
> > > > - Original Message -
> >
- Original Message -
> On 06/26/2018 10:40 AM, David Wysochanski wrote:
> > On Tue, 2018-06-26 at 11:27 -0400, Dave Anderson wrote:
> >>
> >> - Original Message -
> >>> On Tue, 2018-06-26 at 15:34 +0100, Jeremy Harris wrote:
> >>&g
- Original Message -
> On Tue, 2018-06-26 at 11:27 -0400, Dave Anderson wrote:
> >
> > - Original Message -
> > > On Tue, 2018-06-26 at 15:34 +0100, Jeremy Harris wrote:
> > > > On 06/26/2018 03:29 PM, David Wysochanski wrote:
> > >
- Original Message -
> On Tue, 2018-06-26 at 15:34 +0100, Jeremy Harris wrote:
> > On 06/26/2018 03:29 PM, David Wysochanski wrote:
> > > On Tue, 2018-06-26 at 09:21 -0400, Dave Anderson wrote:
> > > > Yes, by default all list entries encountered are pu
- Original Message -
> Hi Dave,
>
> We have a fairly large vmcore (around 250GB) that has a very long kmem
> cache we are trying to determine whether a loop exists in it. The list
> has literally billions of entries. Before you roll your eyes hear me
> out.
>
> Just running the follo
- Original Message -
> > Update, If I try to open with command: "crash -d1 ..." I get:
> > [root@centos511test kernel]# crash -d1 vmcore
> > /usr/lib/debug/lib/modules/`uname -r`/vmlinux
> >
> > crash 5.1.8-3.el5.centos
> > Copyright (C) 2002-2011 Red Hat, Inc.
> > Copyright (C) 2004,
> Update, If I try to open with command: "crash -d1 ..." I get:
> [root@centos511test kernel]# crash -d1 vmcore
> /usr/lib/debug/lib/modules/`uname -r`/vmlinux
>
> crash 5.1.8-3.el5.centos
> Copyright (C) 2002-2011 Red Hat, Inc.
> Copyright (C) 2004, 2005, 2006 IBM Corporation
> Copyright (C) 19
- Original Message -
> Hi Dave,
>
> I'm faced with abort in "kmem -i" command with some vmcores
> and looking into it, but I haven't found the cause so far.
> Could you possibly take a look at this issue?
>
> I attached the abort log. I can send you the core and vmcore.
>
> Depending o
- Original Message -
>
> Since kernel commit c2b4d8b7417a ("powerpc/mm/hash64: Increase the VA
> range"), the max virtual (effective) address value has been increased
> to 4PB. Update page table index values accordingly.
>
> Signed-off-by: Hari Bathini
Hari,
Thanks for the quick respon
- Original Message -
> Hi Dave,
>
> I'm faced with abort in "kmem -i" command with some vmcores
> and looking into it, but I haven't found the cause so far.
> Could you possibly take a look at this issue?
>
> I attached the abort log. I can send you the core and vmcore.
>
> Depending
- Original Message -
> Hi Dave, hi co,
>
> I noticed a behaviour change regarding System.map handling regarding
> newer kernel like 4.14+
>
> As a example:
> below command works:
> crash -d 1 vmlinux-4.14.43-1-pserver ps402a-30-dump.201806041421 > good.txt
>
> below command report erro
Kazuhito,
Your patch is queued for crash-7.2.4:
https://github.com/crash-utility/crash/commit/46d2121960d81354facf4e2558c81f82257b740e
Thanks,
Dave
- Original Message -
> kernel commit 2456e855354415bfaeb7badaa14e11b3e02c8466 ("ktime: Get
> rid of the union") switched ktime_t
On vacation, back next week.
Dave
Sent from my Verizon, Samsung Galaxy smartphone
Original message From: Kazuhito Hagio
Date: 5/21/18 5:31 PM (GMT-05:00) To: crash-utility@redhat.com Subject:
[Crash-utility] [PATCH] fix for "timer -r" error: invalid structure
member offse
ash utility was built with. Fortunately Alex Sidorenko caught one
of the bugs, and upon code inspection, I found two more. Since the fixes
caused fairly serious regressions, this immediate new release is the best
course of action. I apologize for any inconvenience this may have caused.
Download
the fix
later today.
Dave
- Original Message -
>
>
> - Original Message -
> > Alex,
> >
> > Just for a sanity check, can you try rebuilding without this 7.2.2 patch:
> >
> > commit 11eceac4ef54e9bf7d64ce3c96a7454aeb126fd8
> >
- Original Message -
> Alex,
>
> Just for a sanity check, can you try rebuilding without this 7.2.2 patch:
>
> commit 11eceac4ef54e9bf7d64ce3c96a7454aeb126fd8
> Author: Dave Anderson
> Date: Fri Apr 20 14:37:52 2018 -0400
>
> Fixes to address
Alex,
Just for a sanity check, can you try rebuilding without this 7.2.2 patch:
commit 11eceac4ef54e9bf7d64ce3c96a7454aeb126fd8
Author: Dave Anderson
Date: Fri Apr 20 14:37:52 2018 -0400
Fixes to address several gcc-8.0.1 compiler warnings that are generated
when building with
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
- Original Message -
> When a task used prctl(PR_SET_MM, PR_SET_MM_ARG_{START,END}, ...)
> (e.g. the systemd's child "(sd-pam)" in Fedora), the "ps -a" option
> could fail with "ps: cannot allocate any more memory!".
Good catch! Queued for crash-7.2.2:
https://github.com/crash-uti
- Original Message -
... [ cut ] ...
> diff --git a/tools.c b/tools.c
> index cd8947147480..b09e564fd3cc 100644
> --- a/tools.c
> +++ b/tools.c
> @@ -3946,6 +3946,10 @@ cmd_tree()
>
> break;
>
> + case 'l':
> +
- Original Message -
> Daniel Vacek (3):
> tree: no need to bail out on tree corruption
> tree: add an option to dump the tree sorted
> tree: document that type defaults to rbtree
>
> defs.h | 1 +
> help.c | 60 ++--
> to
- Original Message -
> Without this patch, the "ps -r" command takes one minute or more per 1,000
> tasks. The cause is that getting the length of {task,signal}_struct.rlim
> array takes some time and it is done for each task.
>
> This patch stores the value, and it will take only about
- Original Message -
> On Tue, Apr 10, 2018 at 8:20 AM Dave Anderson wrote:
>
> > - Original Message -
> > > This series decreases crash startup and 'ps' processing time when
> > > handling dumps
> > > with many tasks. Prior
- Original Message -
> On Thu, Apr 12, 2018 at 3:57 PM, Dave Anderson wrote:
> >
> > Daniel,
> >
> > Hmmm, when looking at your example, I just noticed it didn't use the -t
> > argument,
> > but then looking at the code realized that the com
- Original Message -
> Hi Dave,
>
> On Thu, Apr 12, 2018 at 3:32 PM, Dave Anderson wrote:
> >
> > Hi Daniel,
> >
> > If the tree is corrupted, I would think that you would want to know the
> > specifics, i.e., aside from the somewhat cryptic read
Daniel,
Hmmm, when looking at your example, I just noticed it didn't use the -t
argument,
but then looking at the code realized that the command defaults to rbtrees. I
actually don't think that was the original intent, but maybe that fact should
should be indicated in the help page? Although
Hi Daniel,
If the tree is corrupted, I would think that you would want to know the
specifics, i.e., aside from the somewhat cryptic readmem() error message.
Perhaps it would be worth printing a more meaningful error message,
something like:
tree: rb_node: : corrupt rb_left pointer:
That
- Original Message -
> This series decreases crash startup and 'ps' processing time when handling
> dumps
> with many tasks. Prior to the series a 1M task dump took 45m to load and 45m
> more to run ps. Once patched, startup+ps time drops below 40 seconds.
Thanks Greg -- the patch is
- Original Message -
>
>
> - Original Message -
> > task_exists() scans known tasks for a given task address.
> >
> > refresh_radix_tree_task_table() looks like:
> > hq_open()
> > for cpus {
> > hq_enter(per_cpu_idle_thread)
> > }
> > for ... {
> > hq_enter(task
- Original Message -
> task_exists() scans known tasks for a given task address.
>
> refresh_radix_tree_task_table() looks like:
> hq_open()
> for cpus {
> hq_enter(per_cpu_idle_thread)
> }
> for ... {
> hq_enter(task)
> }
> hq_close()
>
> tt->running_tasks = 0
>
201 - 300 of 3204 matches
Mail list logo
