Re: [Crash-utility] Questions on multi-thread for crash

2023-02-22 Thread David Wysochanski
On Wed, Feb 22, 2023 at 1:57 AM Tao Liu wrote: > > Hi David, > > > On Tue, Feb 21, 2023 at 4:14 AM David Wysochanski wrote: > > > > On Tue, Feb 7, 2023 at 11:34 PM Tao Liu wrote: > > > > > > Hello, > > > > > > Recently

Re: [Crash-utility] Questions on multi-thread for crash

2023-02-20 Thread David Wysochanski
On Tue, Feb 7, 2023 at 11:34 PM Tao Liu wrote: > > Hello, > > Recently I made an attempt to introduce a thread pool for crash utility, to > optimize the performance of crash. > > One obvious point which can benefit from multi-threading is > memory.c:vm_init(). > There are hundreds of

Re: [Crash-utility] [PATCH] ppc64: still allow to move on if the emergency stacks info fails to initialize

2022-10-05 Thread David Wysochanski
On Tue, Oct 4, 2022 at 10:22 PM Lianbo Jiang wrote: > > Currently crash will fail and then exit, if the initialization of > the emergency stacks information fails. In real customer environments, > sometimes, a vmcore may be partially damaged, although such vmcores > are rare. For example: > > #

Re: [Crash-utility] [PATCH] arm64: Fix segfault by "bt" command with offline cpus

2022-01-26 Thread David Wysochanski
On Wed, Jan 26, 2022 at 1:08 AM HAGIO KAZUHITO(萩尾 一仁) wrote: > > Currently on arm64, NT_PRSTATUS notes in dumpfile are not mapped to > online cpus and machine_specific->panic_task_regs correctly. As a > result, the "bt" command can cause a segmentation fault. > > crash> bt -c 0 > PID: 0

Re: [Crash-utility] crash does not work with last fedora kernels?

2021-08-02 Thread David Wysochanski
On Mon, Aug 2, 2021 at 7:35 AM David Wysochanski wrote: > > On Sat, Jul 31, 2021 at 5:33 AM lijiang wrote: > > > > > Here's the feedback, cut/pasted from the other email thread: > > > > > Thank you for the feedback. > > > > > I'm seeing a l

Re: [Crash-utility] crash does not work with last fedora kernels?

2021-08-02 Thread David Wysochanski
On Sat, Jul 31, 2021 at 5:33 AM lijiang wrote: > > > Here's the feedback, cut/pasted from the other email thread: > > > Thank you for the feedback. > > > I'm seeing a lot of "invalid input" displayed like the below when > > using the 'bt' command. Is this a known issue? > > > > Yes. This is a

Re: [Crash-utility] crash does not work with last fedora kernels?

2021-07-30 Thread David Wysochanski
e and kernel images? Or provide an intructions how to > recreate this core? > I would be nice if you perform set of testing with your cores! > Thanks, > --Alexey > > On 7/30/21, 7:44 AM, "crash-utility-boun...@redhat.com on behalf of David > Wysochanski" dwyso...@redha

Re: [Crash-utility] crash does not work with last fedora kernels?

2021-07-30 Thread David Wysochanski
On Thu, Jul 29, 2021 at 9:57 PM lijiang wrote: > > > > > Hi, David > > Thank you for the attention. > > Currently, Fedora kernel has been forced to generate the DWARF4 debuginfo > > via the > > CONFIG_DEBUG_INFO_DWARF4 kernel option, see jforbes' comment: > >

Re: [Crash-utility] Crash-utility Digest, Vol 190, Issue 20

2021-07-29 Thread David Wysochanski
On Wed, Jul 28, 2021 at 10:21 PM lijiang wrote: >> >> On 7/28/21, 11:14 AM, "crash-utility-boun...@redhat.com on behalf of >> David Wysochanski" > dwyso...@redhat.com> wrote: >> >> On Wed, Apr 28, 2021 at 8:54 AM lijiang wrote: >&g

Re: [Crash-utility] crash does not work with last fedora kernels?

2021-07-28 Thread David Wysochanski
nvalid input: "jne" bt: invalid input: "mov" bt: invalid input: "je" bt: invalid input: "call" > On 7/28/21, 1:23 PM, "Alexey Makhalov" wrote: > > DWARF-5 support was added in GDB-8.0. There GDB update to version 10.2 is &g

Re: [Crash-utility] crash does not work with last fedora kernels?

2021-07-28 Thread David Wysochanski
On Wed, Apr 28, 2021 at 8:54 AM lijiang wrote: > > 在 2021年04月26日 19:17, crash-utility-requ...@redhat.com 写道: > > Message: 3 > > Date: Mon, 26 Apr 2021 11:27:40 +0300 > > From: Vasily Averin > > To: crash-utility@redhat.com > > Subject: [Crash-utility] crash does not work with last fedora

[Crash-utility] Is there an estimated date for crash-7.2.9?

2020-09-16 Thread David Wysochanski
Just wondering if the next release is on the horizon or any estimated date? -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility

Re: [Crash-utility] Suggestion: Testing of crash patches before submissions

2020-08-17 Thread David Wysochanski
On Fri, Aug 14, 2020 at 4:27 AM HAGIO KAZUHITO(萩尾 一仁) wrote: > > -Original Message- > > Hi all, > > > > Recently I found a regression and also in the past have seen other > > regressions. I am not sure what tests are currently run or expected > > for patches. > > > > Since this project

Re: [Crash-utility] Crash-utility Digest, Vol 179, Issue 4

2020-08-15 Thread David Wysochanski
On Thu, Aug 13, 2020 at 8:47 PM HAGIO KAZUHITO(萩尾 一仁) wrote: > > -Original Message- > > From: crash-utility-boun...@redhat.com > > On Behalf Of lijiang > > Sent: Friday, August 14, 2020 8:31 AM > > To: David Wysochanski > > Cc: Discussion list

Re: [Crash-utility] Crash-utility Digest, Vol 179, Issue 4

2020-08-13 Thread David Wysochanski
On Thu, Aug 13, 2020 at 9:08 AM lijiang wrote: > > 在 2020年08月13日 16:33, David Wysochanski 写道: > > Hi Lianbo > > > > On Sat, Aug 8, 2020 at 10:46 PM lijiang wrote: > >> > >> 在 2020年08月07日 00:00, crash-utility-requ...@redhat.com 写道: > >>>

[Crash-utility] Suggestion: Testing of crash patches before submissions

2020-08-13 Thread David Wysochanski
Hi all, Recently I found a regression and also in the past have seen other regressions. I am not sure what tests are currently run or expected for patches. Since this project has transitioned away from the original author, and there are many contributors, it may be more important to have some

Re: [Crash-utility] Crash-utility Digest, Vol 179, Issue 4

2020-08-13 Thread David Wysochanski
Hi Lianbo On Sat, Aug 8, 2020 at 10:46 PM lijiang wrote: > > 在 2020年08月07日 00:00, crash-utility-requ...@redhat.com 写道: > > Message: 5 > > Date: Thu, 6 Aug 2020 09:30:22 -0400 > > From: Dave Wysochanski > > To: crash-utility@redhat.com > > Subject: [Crash-utility] [PATCH v3] Fix "log" command

Re: [Crash-utility] [PATCH] Fix "log" command when crash is started with "--minimal" option

2020-08-06 Thread David Wysochanski
On Thu, Aug 6, 2020 at 9:25 AM Dave Wysochanski wrote: > > Commit c86250bce29f introduced the useful '-T' option to print the > log timestamp in human-readable form. However, this option does > not work when crash is invoked with '--minimal' mode, and if tried, > crash will spin at 100% and

[Crash-utility] regression: crash --minimal "log" command spins at 100% cpu after c86250bce29f Introduction of the "log -T" option

2020-08-04 Thread David Wysochanski
This patch broke running "log" command when "crash --minimal" is invoked for any vmcore. This is important because sometimes there is a damaged vmcore and the log is enough to diagnose the problem. It looks like this is the result of this code block where machdep->hz == 0 and we divide by 0: @@

Re: [Crash-utility] crash-7.3.2 very long list iteration progressively increasing memory usage

2018-07-02 Thread David Wysochanski
On Sat, 2018-06-30 at 21:11 -0400, David Wysochanski wrote: > On Fri, 2018-06-29 at 12:04 +0100, Jeremy Harris wrote: > > On 06/28/2018 11:09 PM, David Wysochanski wrote: > > > One problem with all of these non-storage location algorithms is that > > > it won't gi

Re: [Crash-utility] crash-7.3.2 very long list iteration progressively increasing memory usage

2018-06-30 Thread David Wysochanski
On Fri, 2018-06-29 at 12:04 +0100, Jeremy Harris wrote: > On 06/28/2018 11:09 PM, David Wysochanski wrote: > > One problem with all of these non-storage location algorithms is that > > it won't give you the precise location of the start of the loop in the > > list (i.e. the o

Re: [Crash-utility] crash-7.3.2 very long list iteration progressively increasing memory usage

2018-06-28 Thread David Wysochanski
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 put in the built-in > > > hash queue, s

Re: [Crash-utility] crash-7.3.2 very long list iteration progressively increasing memory usage

2018-06-27 Thread David Wysochanski
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 put in the built-in > > > hash queue, s

Re: [Crash-utility] crash-7.3.2 very long list iteration progressively increasing memory usage

2018-06-26 Thread David Wysochanski
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 - > > > > On Tue, 2018-06-26 at 15:34 +0100, Jeremy Harris wrot

Re: [Crash-utility] crash-7.3.2 very long list iteration progressively increasing memory usage

2018-06-26 Thread David Wysochanski
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: > > > > On Tue, 2018-06-26 at 09:21 -0400, Dave Anderson wro

Re: [Crash-utility] crash-7.3.2 very long list iteration progressively increasing memory usage

2018-06-26 Thread David Wysochanski
On Tue, 2018-06-26 at 09:21 -0400, Dave Anderson wrote: > > - 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.

[Crash-utility] crash-7.3.2 very long list iteration progressively increasing memory usage

2018-06-26 Thread David Wysochanski
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 following command crash> list -H 0x8ac03c81fc28