Fix for the "bpf -m|-M" options on Linux 5.3 and later kernels that
contain commit 3539b96e041c06e4317082816d90ec09160aeb11, titled
"bpf: group memory related fields in struct bpf_map_memory".
Without the patch, the options prints "(unknown)" for MEMLOCK and UID.
Signed-off-by: Kazuhito Hagio
"bpftool prog list" command displays eBPF program name if available.
Also, the crash "bpf -m|-M" options display eBPF map name. But the
"bpf -p|-P" options don't display its name. It would be useful in
finding the program which we want to see.
Signed-off-by: Kazuhito Hagio
---
bpf.c | 12
> -Original Message-
> - Original Message -
> > ccing kexec list, vmcore-dmesg also uses vmcoreinfo related to printk..
> >
> > > -Original Message-
> > >
> > > - Original Message -
> > > > Hello Dave,
> > > >
> > > > You may or may not be aware that we are working
ccing kexec list, vmcore-dmesg also uses vmcoreinfo related to printk..
> -Original Message-
>
> - Original Message -
> > Hello Dave,
> >
> > You may or may not be aware that we are working on replacing [0] the
> > Linux printk ringbuffer. Rather than a single buffer containing a
Hi John,
> -Original Message-
> Hi Kazu,
>
> Here is a patch adding full support for the new lockless printk
> ringbuffer as it is currently being proposed. Note that the latest
> version has not yet been submitted to LKML. I was waiting until I
> finished tests with crash(8) and
> -Original Message-
> > -Original Message-
> > - Original Message -
> > > ccing kexec list, vmcore-dmesg also uses vmcoreinfo related to printk..
> > >
> > > > -Original Message-
> > > >
> > > > - Original Message -
> > > > > Hello Dave,
> > > > >
> > > > >
> -Original Message-
> - Original Message -
> > Dave,
> >
> > > Initially Kazuhito will primarily be handling upstream github duties,
> > > while Lianbo and Bhupesh will be handling Fedora, CentOS stream, and
> > > RHEL maintenance. All three will be involved in the acceptance of
-Original Message-
> Calls to x86_64_exception_frame() with combined items set in the flags
> argument that include EFRAME_VERIFY do not have the EFRAME_VERIFY
> operation performed. I have some cores where multiple cases of
> attempting to read a not-present pt_regs end a single PID
Hi Lianbo,
Thank you for reviewing this.
-Original Message-
...
> > /*
> > + * Convert a calendar time into a null-terminated string like ctime(), but
> > + * the result string contains the time zone string and does not ends with a
> > + * linefeed ('\n'). If localtime() or strftime()
Hi Arun,
-Original Message-
> Hi,
>
> I was trying to debug a PPC64 crash from a X86_64 machine. I got crash
> (7.2.8) to work with a "make
> target=PPC64", but when I tried to load an extension I got this error:
>
>
> crash> extend
>
-Original Message-
> Hi Kazu,
>
> I swear that last week I couldn't build past:
>
> verify_addr = (local - bt->stackbuf) + bt->stackbase;
>
> without a gcc error on the two char * in the parentheses being
> used in a ulong assignment. Last week it required casts on both
> char * to
-Original Message-
...
> >> If verifying local argument, translate to a kernel address range using
> >> the stackbuf and stackbase members of the bt argument the same way used
> >> for EFRAME_SEARCH later in x86_64_exception_frame(). local and
> >> bt->stackbuf are char *, the assignment
-Original Message-
> Kernel commit fe557319aa06c23cffc9346000f119547e0f289a renamed
> probe_kernel_{read,write} to copy_{from,to}_kernel_nofault.
>
> Additionally, commit 0493cb086353e786be56010780a0b7025b5db34c
> unexported probe_kernel_write(), so writing kernel memory is
> no longer
-Original Message-
> 在 2020年09月11日 14:01, HAGIO KAZUHITO(萩尾 一仁) 写道:
> > Hi Lianbo,
> >
> > Thank you for reviewing this.
> >
> > -Original Message-
> > ...
> >>> /*
> >>> + * Convert a calendar time into a null-termina
,
Kazu
>
> Thanks,
> Mathias
>
> [1] https://www.redhat.com/archives/crash-utility/2020-August/msg00021.html
>
> Am 25.08.20 um 04:09 schrieb HAGIO KAZUHITO(萩尾 一仁):
> > -Original Message-
> >> PaX and grsecurity kernels split module memory into dedicated r/x an
-Original Message-
> On 9/1/20 8:35 PM, HAGIO KAZUHITO(萩尾 一仁) wrote:
> > -Original Message-
> >> Calls to x86_64_exception_frame() with combined items set in the flags
> >> argument that include EFRAME_VERIFY do not have the EFRAME_VERIFY
> >> op
-Original Message-
> 在 2020年09月03日 07:43, HAGIO KAZUHITO(萩尾 一仁) 写道:
> > Hi Lianbo,
> >
> > -Original Message-
> >> Does this need further input from my site to get merged? Lianbo acked an
> >> earlier version[1], so this should be fine a
Hi Valentin,
Thanks for the patchset.
I've cc'd this to the maintainer of the trace extension.
Xu Huan, could you please review the patchset?
(Apparently, Xu could not respond in March 2019, though.. [1]
Does anyone in Fujitsu know who can maintain this?)
[1]
Hi David,
Thanks for the update.
> -Original Message-
> x86_64_exception_frame() called with combined flags including
> EFRAME_VERIFY does not perform the verify. It's only done when
> EFRAME_VERIFY is the only flag set.
>
> Correct the condition to EFRAME_VERIFY if the flag is set.
-Original Message-
> On Thu, 1 Oct 2020 00:38:23 +
> HAGIO KAZUHITO(萩尾 一仁) wrote:
>
> > Hi Alex,
> >
> > sorry for the delayed response.
> >
> > I misunderstood at first glance and have waited for the kernel patch
> > adding the vmcorein
Hi Alexey,
thanks for the patch, I've commented a few inline.
-Original Message-
> vmware_guestdump is extension to vmware_vmss with ability to debug
> debug.guest and debug.vmem files.
>
> debug.guest.gz and debug.vmem.gz can be obtained using following
> .vmx options from VM running
-Original Message-
> vmware_guestdump is extension to vmware_vmss with ability to debug
> debug.guest and debug.vmem files.
>
> debug.guest.gz and debug.vmem.gz can be obtained using following
> .vmx options from VM running in debug mode:
> monitor.mini-suspend_on_panic = TRUE
>
-Original Message-
> Reserved fields in SMRAM CPU states could be non-zero even if the
> corresponding APICs are NOT used. This breaks the assumption that
> SMRAM CPU state is zero cleared if and only if the APIC corresponding
> to the entry is NOT used. As the result, help -D lists
Hi Alex,
Thanks for the patch.
-Original Message-
> - Introduce CONF_CC variable to compile configure.c
> - Introduce CONF_HOST_ARCH to configure.c to enable overriding target
> at compile time
Could you add an example usage for more information at least here?
It would be better to
-Original Message-
> 在 2020年10月13日 03:37, Alexey Makhalov 写道:
> > It will allow to initialize and to use vmss from outside.
> > Also move some useful macros to vmware_vmss.h file.
> >
> > This is a preparation for the following commit to extend vmss
> > functionality.
> >
> Thank you for
-Original Message-
> 在 2020年10月15日 08:14, HAGIO KAZUHITO(萩尾 一仁) 写道:
> > Hi Lianbo,
> >
> > -Original Message-
> >>> Date: Thu, 24 Sep 2020 08:16:06 +
> >>> From: HAGIO KAZUHITO(?)
> >>> To:
Hi Lianbo,
-Original Message-
> > Date: Thu, 24 Sep 2020 08:16:06 +
> > From: HAGIO KAZUHITO(?)
> > To: "Discussion list for crash utility usage, maintenance and
> > development"
> > Subject: [Crash-utility] [PATCH] Fix for failure when using extensions
> >
-Original Message-
> 在 2020年10月02日 00:00, crash-utility-requ...@redhat.com 写道:
> > Message: 2
> > Date: Thu, 1 Oct 2020 15:19:59 +0200
> > From: Alexander Egorenkov
> > To: crash-utility@redhat.com, k-hagio...@nec.com
> > Subject: [Crash-utility] [PATCH v2 1/1] Support member offset
> >
Hi Alex,
Thanks for updating this.
-Original Message-
> The offset of the field 'init_uts_ns.name' has changed
> since commit 9a56493f6942 ("uts: Use generic ns_common::count").
>
> Link:
> https://lore.kernel.org/r/159644978167.604812.1773586504374412107.stgit@localhost.localdomain
>
-Original Message-
> In order to support cross-compilation of crash-utilty,
> the configure tool compiled from configure.c must be built
> for the host architecture where the cross-compilation will run
> instead of the target architecture where the crash-utility shall run.
> Therefore, we
-Original Message-
> 在 2020年09月04日 21:53, crash-utility-requ...@redhat.com 写道:
> > Date: Thu, 3 Sep 2020 21:28:45 +0100
> > From: Valentin Schneider
> > To: crash-utility@redhat.com
> > Subject: [Crash-utility] [PATCH 0/2] extensions/trace: Sync up with
> > v5.8struct renaming
>
This patch got 2 acks, applied:
https://github.com/crash-utility/crash/commit/79e756606c9fca3407f70403f6566b5f6be2b292
Thanks,
Kazu
-Original Message-
> 在 2020年10月07日 00:00, crash-utility-requ...@redhat.com 写道:
> > Date: Tue, 6 Oct 2020 21:05:39 +0900
> > From: HATAYAMA Daisuke
> >
Hi Alexey,
thanks for the comments and update.
-Original Message-
> diff --git a/defs.h b/defs.h
> index c899fe2..f61f864 100644
> --- a/defs.h
> +++ b/defs.h
> @@ -655,6 +655,7 @@ struct new_utsname {
> #define IRQ_DESC_TREE_RADIX(0x40ULL)
> #define IRQ_DESC_TREE_XARRAY
-Original Message-
> Hi, Mathias
>
> Thank you for discussing this topic and describing its backgrounds.
>
> 在 2020年08月19日 23:45, Mathias Krause 写道:
> > Hi list,
> >
> > during development of the PaX module patch[1], Lianbo pointed out an
> > issue about adding new members to struct
-Original Message-
> 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.
On kernels that contain commit 9df872faa7e1 ("genirq: Move field
'affinity' from irq_data into irq_common_data"), without the patch,
the "irq -a" option cannot work with the message "irq: -a option not
supported or applicable on this architecture or kernel".
Signed-off-by: Kazuhito Hagio
---
On kernels that contain commit 1008fe6dc36d ("block: remove the all_bdevs
list"), without the patch, the "kmem -i" option fails halfway with the
error message 'kmem: cannot resolve: "all_bdevs"'.
Signed-off-by: Kazuhito Hagio
---
# sorry, resending this because I sent with inappropriate
Currently it's not easy to distinguish which time zone the output of
DATE uses:
crash> sys | grep DATE
DATE: Thu Nov 29 06:44:02 2018
Let's introduce ctime_tz() function like ctime() but explicitly appends
the time zone to its result string.
DATE: Thu Nov 29 06:44:02 JST 2018
-Original Message-
> Hi Lianbo,
>
> Please note that we still need to formulate a way to maintain
> crash-extension outside a tarball.
> I am preparing a RFC proposal and will share it shortly.
FYI, the maintainer of gcore is Daisuke (Hatayama-san), so I think he
will review the patch
Currently it's not easy to distinguish which time zone the output of
DATE uses:
crash> sys | grep DATE
DATE: Thu Nov 29 06:44:02 2018
Let's introduce ctime_tz() function like ctime() but explicitly appends
the time zone to its result string.
DATE: Thu Nov 29 06:44:02 JST 2018
Hi Mathias,
Thanks for the review!
-Original Message-
> Hi Kazuhito,
>
> Am 19.08.20 um 08:32 schrieb HAGIO KAZUHITO(萩尾 一仁):
> > Currently it's not easy to distinguish which time zone the output of
> > DATE uses:
> >
> > crash> sys | grep DATE
&
-Original Message-
> PaX and grsecurity kernels split module memory into dedicated r/x and
> r/w mappings using '*_rw' and '*_rx' named member variables in 'struct
> module'. To add basic support for such kernels detect the split layout
> by testing for the corresponding structure members
-Original Message-
> PaX and grsecurity kernels split module memory into dedicated r/x and
> r/w mappings using '*_rw' and '*_rx' named member variables in 'struct
> module'. To add basic support for such kernels detect the split layout
> by testing for the corresponding structure members
From: Goodbach
Date: Wed, 12 Aug 2020 11:22:29 +0800
Resolves: https://github.com/crash-utility/crash/pull/61
Signed-off-by: Goodbach
---
xendump.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/xendump.c b/xendump.c
index 70cf261..a81817d 100644
--- a/xendump.c
+++
Bhupesh, Lianbo,
I have certainly cc'd Xu Huan (not seen in the email sent by the list for
some reason though), but no response for two weeks. so let's review this.
Valentin, please wait for a while.
Thanks,
Kazu
-Original Message-
> Hi Valentin,
>
> Thanks for the patchset.
> I've
-Original Message-
> From: Goodbach
> Date: Wed, 12 Aug 2020 11:22:29 +0800
>
> Resolves: https://github.com/crash-utility/crash/pull/61
> Signed-off-by: Goodbach
I'm not sure whether it's needed to also add the ARM one to 32-bit side,
but the patch itself looks good to me.
Acked-by:
Without the patch, the "extend" command on an x86_64 binary that can
be used to analyze ppc64le dumpfiles fails with the error meesage
"extend: : not an ELF format object".
Suggested-by: Arun Easi
Signed-off-by: Kazuhito Hagio
---
I'm not sure which tag I should use in this case, so if you want
-Original Message-
> Hi,
>
> Trying to use the trace extension on a mainline kernel doesn't work, and it
> stems from some struct renaming that has happened upstream.
>
> These two patches update the internal naming to match the upstream one, and
> includes some backwards-compatibility
Hi Alex,
sorry for the delayed response.
I misunderstood at first glance and have waited for the kernel patch
adding the vmcoreinfo entry you posted, but I just found no need to
wait for it with respect to crash.
-Original Message-
> The offset has changed in linux-next (v5.9.0) from 4
-Original Message-
> Just wondering if the next release is on the horizon or any estimated date?
We are planning the next release in early November for now.
Thanks,
Kazu
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
Hi Hatayama-san,
sorry, we've not been able to make a time to review this patchset.
probably I can next week.
Thanks,
Kazu
-Original Message-
> Hi,
>
> Are there any comments for this patch set?
>
> Without this patch set, I'll drop zram feature in the next release of crash
> gcore
-Original Message-
>
>
> 在 2020年10月14日 20:19, lijiang 写道:
> > 在 2020年09月24日 15:41, crash-utility-requ...@redhat.com 写道:
> >> Message: 3
> >> Date: Thu, 24 Sep 2020 07:41:37 +
> >> From: HAGIO KAZUHITO(?)
> >> To: "Discussion list for crash utility usage, maintenance
> -Original Message-
> From: HATAYAMA Daisuke
>
> In numeric_forward(), care must be taken both for x- and y- positions,
> but either of kaiser_init and pti_init is only for x- or y- position
> only. Fix this. Also, move the code in an appropriate position
> according to each symbol name
Hi Hatayama-san,
sorry for the delay.
> -Original Message-
> This patch series fix failure of calculating kaslr_offset due to an
> sadump format restriction.
>
> The main part is the 4-th patch. I found some small bugs during this
> work and the 2nd and 3rd are to fix them and are also
> -Original Message-
> From: HATAYAMA Daisuke
>
> We faced recently a memory dump collected by sadump where unused part
> of register values are non-zero. For the crash dump, calculating
> kaslr_offset fails because it is based on the assumption that unused
> part of register values in
> -Original Message-
> Since linux kernel commit bbdbc11804ff ("arm64/crash_core: Export
> TCR_EL1.T1SZ in
> vmcoreinfo") [available in linux-next now], the name of tcr_el1_t1sz
> vmcoreinfo variable has been changed to TCR_EL1_T1SZ.
>
> Make a similar change in crash-utility.
>
>
Hi Bhupesh,
sorry for the late response.
> -Original Message-
> Update the Makefile comments to note that arm and arm64
> are also supported build targets.
>
> Signed-off-by: Bhupesh Sharma
> ---
> Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
Hi Mathias,
-Original Message-
> The parser's debug log is missing a few line breaks as well as some
> crucial information, like control register dumps.
>
> Add them for read- and debugability.
>
> Signed-off-by: Mathias Krause
> ---
> vmware_vmss.c | 11 ++-
> 1 file changed,
-Original Message-
> From: crash-utility-boun...@redhat.com On
> Behalf Of Mathias Krause
> Sent: Sunday, August 9, 2020 12:18 AM
> To: crash-utility@redhat.com
> Cc: liji...@redhat.com
> Subject: [Crash-utility] [PATCH v2 0/3] vmss/core related fixes and
> enhancements
>
> This small
Hi Lianbo,
> -Original Message-
> 在 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 when crash is
> >
-Original Message-
> From: crash-utility-boun...@redhat.com On
> Behalf Of Andrej Ras
> Sent: Friday, July 31, 2020 2:48 AM
> To: crash-utility@redhat.com
> Subject: [Crash-utility] using crash without vmlinux OR dump memory at
> specific vaddr
>
> Hi Folks,
>
> I have a simple
-Original Message-
> Maybe some of the warnings in WARNING_OPTIONS should be enabled by default?
Thanks for the idea.
The default has minimum flags, I think it's easy to customize by distributors,
and probably most crash users don't need the warnings. Personally I would like
developers
-Original Message-
> >> In addition, might it be more reasonable to issue a warning instead of a
> >> fatal error?
> >
> > hmm, why do you think so? I think FATAL is fine because we cannot proceed
> > anymore and there is no memory to be released.
> >
> When users are trying to use the
-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 for crash utility usage, maintenance and development
>
> Subject: Re: [Crash-utility] Crash-utility Digest, Vol 179,
Hi Lianbo, Bhupesh,
Is it possible for both of you to review/test this patchset?
i.e. merge without my ack. It would be better to test on real machine
and the vmcores for test that Dave left.
Thanks,
Kazu
-Original Message-
> With kernel commit ecb1ff6833 "s390/debug: remove raw view"
Hi Bhupesh,
-Original Message-
> > Just FYI, with respect to the System.map file, the following Dave's post
> > would be helpful:
> > https://www.redhat.com/archives/crash-utility/2018-June/msg2.html
> >
> > If you have the vmlinux corresponding to a running kernel, you don't need
> >
-Original Message-
> Hi,
>
> Thanks, Found it.
>
> So question about this extension:
> I'm trying to create a process core from a vmcore.
> As result I get a correct elf core. But I see that one note, called
> .note.linuxcore.file is missing.
> I implemented there a code to dump this
-Original Message-
> Hello,
>
> I have implemented an improvement for gcore extension.
> However, when I searched for the gcore source code in the main repository ?
> I don’t find it.
> Can you tell me how to find it? Then I can create a patch, and share.
I think
-Original Message-
> 在 2020年06月12日 00:00, crash-utility-requ...@redhat.com 写道:
> > Looks good to me, thank you Li RongQing. Please wait for another ack.
>
> The v2 looks good to me.
>
> Acked-by: Lianbo Jiang
>
> >
> > Acked-by: Kazuhito Hagio
> >
> > If someone can comment or create
-Original Message-
>
> 在 2020年06月15日 22:18, HAGIO KAZUHITO(萩尾 一仁) 写道:
> > -Original Message-
> >> 在 2020年06月12日 00:00, crash-utility-requ...@redhat.com 写道:
> >>> Looks good to me, thank you Li RongQing. Please wait for another ack.
-Original Message-
> > [root@lxkmg-pag-ale test64]# /usr/bin/crash -d 15
> > System.map-4.18.0-147.el8.x86_64 vmlinux.debuginfo vmcore
...
> >
> > read_diskdump: PAGE_EXCLUDED: paddr/pfn: 37b31200/37b31
> > crash: page excluded: kernel virtual address: 82131200 type:
> >
-Original Message-
> > > Crash utility currently does not supporting virtual to physical
> > > address translation for 1G huge pages on x86_64, This patch tries to
> > > address this issue by providing address translation support for huge
> > > pages in 'vtop' command.
> >
> > Good catch!
> -Original Message-
> From: Li RongQing
>
> Crash utility currently does not supporting virtual to physical
> address translation for 1G huge pages on x86_64, This patch tries
> to address this issue by providing address translation
> support for huge pages in 'vtop' command.
Good
-Original Message-
> Crash utility currently does not supporting virtual to physical
> address translation for 1G huge pages on x86_64, This patch tries
> to address this issue by providing address translation
> support for huge pages in 'vtop' command.
>
> Without this patch:
> crash>
Hi Hatayama-san,
Thank you for the new series, it looks good to me.
For the v2 series,
Acked-by: Kazuhito Hagio
Bhupesh, Lianbo, could either of you review this series?
Thanks,
Kazu
-Original Message-
> This patch series fix failure of calculating kaslr_offset due to an
> sadump
Hi Bhupesh,
-Original Message-
> Hi Kazu,
>
> On Wed, Jul 22, 2020 at 1:02 PM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
> >
> > Hi Bhupesh,
> >
> > sorry for the late response.
> >
> > > -Original Message-
> > > Update the
Hi Bhupesh,
-Original Message-
> Although we have trace.c uploaded to crash-extensions github currently,
> several users (like RHEL/SUSE rpm packagers), prefer using
> crash-trace-*.tar.gz directly for rpm packaging, lets upload the same to
> github extensions as well.
OK, it looks very
-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 has transitioned away from the original author, and
> there are many
> -Original Message-
> From: crash-utility-boun...@redhat.com On
> Behalf Of Dave Wysochanski
> Sent: Monday, August 17, 2020 4:20 AM
> To: crash-utility@redhat.com
> Subject: [Crash-utility] [PATCH v4] Fix "log" command when crash is started
> with "--minimal" option
>
> Commit
Hi Bhupesh,
-Original Message-
> We have hard-coded the HZ value for some ARCHs to either 1000 or 100
> (mainly for kernel versions > 2.6.0), which causes 'help -m' to show
> an incorrect hz value for various architectures.
Good catch. but seems crash uses (cfq_slice_async * 25) for
-Original Message-
> 在 2020年11月20日 13:56, HAGIO KAZUHITO(萩尾 一仁) 写道:
> > From: John Ogness
> >
> > Linux 5.10 introduces a new lockless ringbuffer. The new ringbuffer
> > is structured completely different to the previous iterations.
> > Add support for dum
Hi Alexey,
Thanks for updating this patch.
-Original Message-
> Linux-5.10 has introduced SEV-ES support. New (5th) exception
> stack was added: 'VC_stack'.
>
> 'struct exception_stacks' cannot be used to obtain size of
> VC stack, as it equals zero there. Try another structure
>
Hi John, Lianbo,
-Original Message-
> On 2020-11-20, HAGIO KAZUHITO(萩尾 一仁) wrote:
> > I've updated John's RFC crash patch to match 5.10-rc4 kernel.
> > Changes from the RFC patch:
> > - followed the following kernel commits
> > cfe2790b163a ("printk
blob pages, but yes, it's a bit strange for binary files.
I will update so later on and let you know.
Thanks,
Kazu
>
> Thanks.
> HATAYAMA, Daisuke
>
>
> ________
> From: HAGIO KAZUHITO(萩尾 一仁)
> Sent: Thursday, December 10, 2020 12:06
&g
Hi Hatayama-san,
-Original Message-
> This is the release of crash gcore command, version 1.6.1.
>
> This release includes the following 1 bug fix.
>
> Hagio-san, could you update the description of crash gcore command
> at https://crash-utility.github.io/extensions.html?
I've updated,
Hi,
Merged the two patches.
https://github.com/crash-utility/crash/compare/bf57c44...71e159c
John, thank you very much for taking care of the userspace tools!
Kazu
-Original Message-
> -Original Message-
> > 在 2020年11月20日 13:56, HAGIO KAZUHITO(萩尾 一仁) 写道:
> > >
-Original Message-
> From: Qianli Zhao
>
> Name Meaning of mapping symbol:
> $x
> $x.
> Start of a sequence of A64 instructions
>
> $c
> $c.
> Start of a sequence of C64 instructions
>
> $d
> $d.
> Start of a sequence of data items (for example, a literal pool)
>
> Reference
Hi Lianbo,
> -Original Message-
> From: crash-utility-boun...@redhat.com On
> Behalf Of lijiang
> Sent: Monday, December 21, 2020 11:42 PM
> To: crash-utility@redhat.com; zhaoqia...@xiaomi.com
> Subject: Re: [Crash-utility] [PATCH V2] netdump: fix regression for tiny
> kdump files
>
>
Hi Lianbo,
> -Original Message-
> From: lijiang
> Sent: Monday, December 21, 2020 11:48 PM
> To: crash-utility@redhat.com; HAGIO KAZUHITO(萩尾 一仁)
> Subject: Re:[PATCH] extensions/eppic.mk: Remove ping check to github.com
> > Without this patch, in an environment whe
Hi Hatayama-san, Bhupesh, Lianbo,
-Original Message-
> Hagio-san,
>
> I'm now preparing for providing crash-gcore-command and
> crash-trace-command packages in Fedora, which has been provided in
> RHEL only so far.
>
> Relevant to that, I'd like to talk about extensions/trace.c about
>
Without this patch, in an environment where ping to github.com does
not work, building eppic.so fails with the message "eppic.so: failed
to pull eppic code from git repo" and "make clean" at the top-level
crash directory unnecessarily takes about 10 seconds every time.
$ time make clean
...
Hi Qianli,
-Original Message-
> From: Qianli Zhao
>
> Commit f42db6a33f0e ("Support core files with "unusual" layout")
> increased the minimal file size from MIN_NETDUMP_ELF_HEADER_SIZE to
> SAFE_NETDUMP_ELF_HEADER_SIZE which lead to crash rejecting very
> small kdump files.
I've not
Hi Alexey,
-Original Message-
> Linux-5.10 has introduced SEV-ES support. New (5th) exception
> stack was added: 'VC_stack'.
>
> 'struct exception_stacks' cannot be used to obtain the size
> of VC stack, as the size of VC stack is zero there. Try
> another structure 'struct
Hi Alexey,
-Original Message-
> Hi Kazu,
>
> >
> > This patch looks good to me and tested ok with some vmcores whose
> > VC stack is not mapped that I have. Thank you for the update.
> >
> > Acked-by: Kazuhito Hagio
> >
>
> Do you want me to update the patch with your ack or you can
Hi Alexey,
Thank you for the huge work! and sorry for the delayed response.
Apparently updating gdb had been done only when kernel required it,
but these days gdb-7.6 has some problems and is old enough, this
update can make crash more useful and future proof.
I need more time to finish
-Original Message-
> Provides API for crash_target to fetch registers of given
> CPU. It will allow gdb to perform such commands as "bt",
> "frame", "info locals".
>
> Highlevel API is crash_get_cpu_reg (). It calls machine
> (architecture) specific function: machdep->get_cpu_reg().
>
-Original Message-
> Looks rightly.
Yes, definitely.
>
> Signed-off-by: Alexey Makhalov
> ---
> help.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/help.c b/help.c
> index d3427a3..60b50fe 100644
> --- a/help.c
> +++ b/help.c
> @@ -8307,6 +8307,7 @@ char *version_info[] =
Hi Lianbo,
-Original Message-
> >>> -GITHUB := $(shell ping -c 1 github.com | grep "1 received")
> >> BTW: Is it possible to fix this issue with the option -W? For example:
> >>
> >> GITHUB := $(shell ping -c 1 -W 2 github.com | grep "1 received")
> >>
> >
Hi Qianli,
Your patch is merged:
https://github.com/crash-utility/crash/commit/31ca172357c4d3520caf29b9efb5e6ccd622aae9
I've added the error message that you showed to the commit log.
Thanks,
Kazu
> -Original Message-
> From: crash-utility-boun...@redhat.com On
> Behalf Of lijiang
>
Hi Alex, Bhupesh,
-Original Message-
> In order to support cross-compilation of crash-utilty,
> the configure tool compiled from configure.c must be built
> for the host architecture where the cross-compilation will run
> instead of the target architecture where the crash-utility shall
1 - 100 of 857 matches
Mail list logo
