Hi,
Thanks for the patch set.
I merged them.
https://github.com/fujitsu/crash-gcore/commit/8ff3de974aa9fdf8934797122dc55428ef571ab2
https://github.com/fujitsu/crash-gcore/commit/1ba701c1d7bd94cc5a02f51652712acdcbf0875c
Note that I edited their commit descriptions. In particular, for the first o
Hi,
Thank you for these patches.
I'm a bit tied up at the moment, but I'll review this until next week.
Please wait for a while.
From: Vincent Whitchurch
Sent: Tuesday, June 21, 2022 18:15
To: crash-utility@redhat.com; Hatayama, Daisuke/畑山 大輔
Cc: Vincen
verify_namelist() uses strings command and scans full part of vmlinux
file to find linux_banner string. However, vmlinux file is quite large
these days, reaching over 500MB. As a result, this degradates start-up
time of crash command 10 or more seconds. (Of course, this depends on
machines you use
Hi,
> Ccing Hatayama-san, as he is the maintainer of the ptdump module:
> https://crash-utility.github.io/extensions.html#PTDUMP
>
> I cannot find the repository for crash-ptdump.
> Do you have any plan to update the module?
Hagio-san, thanks for your letting me know.
Goutham, sorry for late re
Hi,
>
>
> From: crash-utility-boun...@redhat.com on
> behalf of shogo.matsum...@fujitsu.com
> Sent: Thursday, December 16, 2021 16:39
> To: 'crash-utility@redhat.com'
> Subject: [Crash-utility] [PATCH] log: output logs of printk safe buffers
>
> We som
Commit 2f967fb5ebd737ce5eadba462df35935122e8865 (crash_taget:
fetch_registers support) added new member get_cpu_reg in the middle of
struct machdep_table as:
@@ -1013,6 +1013,7 @@ struct machdep_table {
ulong (*processor_speed)(void);
int (*uvtop)(struct task_context
Commit 2fab8fbc0c4f1c4cbe889de4cead5f7457a19f77 (symbols: Implement
install and remove operations for mod_symname_hash) added new member
variable mod_symname_hash in the middle of struct symbol_table_data:
diff --git a/defs.h b/defs.h
index cbd45e5..bbdca79 100644
--- a/defs.h
+++
This is the release of crash gcore command, version 1.6.3.
You can get it at:
https://github.com/fujitsu/crash-gcore/releases/tag/v1.6.3
ChangeLog:
- Adding ZRAM support. To use this feature, crash v7.3.0 or newer is
required.
(d.hatay...@fujitsu.com)
- Setting DT_SONAME field to
Hi,
> On Thu, Nov 12, 2020 at 01:29:06PM +0100, ?乾利 wrote:
> > gcore patch:
> > commit 837182cc6589095c0d08f71f57953c50ad61cc19
> > Author: zhaoqianli
> > Date: Thu Nov 12 19:41:01 2020 +0800
> >
> > Fix register parsing error caused by miscalculation of the
> > starting address of the
Wengang,
Thanks for your patch.
> >From a UEK5 vmcore, I see that
What arch and kernel version do you use?
What is the last kernel version you didn't see this issue?
I need to identify the change in the kernel side that caused this issue.
>
> crash> p &__start___trace_bprintk_fmt
> $1 = (cons
> However, I found that the "make lzo valgrind" might not work well with
> this v1 patch, thanks to Lianbo.
>
> Hatayama-san, do we need to unlink tools.o like lzo and snappy below
> to rebuild tools.c with -DVALGRIND for e.g. "make lzo valgrind" ?
>
> 1757 if ((lzo || snappy) &&
> 1758
> -Original Message-
> > By the way, during this confirmation, I got aware of the fact that we
> > would need to repeat this in the next release as well because the
> > description
> > of crash gcore command includes its version information... To simplify
> > this, how about just pointing
Hagio-san,
> > Hagio-san, could you update descriptions for gcore.c and trace.c in
> > https://crash-utility.github.io/extensions.html accordingly?
>
> Thank you for creating the repositories, updated the descriptions.
> We will remove extensions/trace.c from the crash repository later.
>
Thanks
Hi, Hagio, Lianbo,
> Sent: Thursday, January 21, 2021 13:44
> For preparing git repos for crash-gcore and crash-trace command,
> I'm working now but a little delayed. Please wait for some more time.
Sorry for the late notification.
I created the git repos as follows:
https://github.com/fujits
Any comments?
Thanks.
HATAYAMA, Daisuke
From: HATAYAMA Daisuke
Sent: Thursday, December 31, 2020 17:20
To: crash-utility@redhat.com
Cc: Hatayama, Daisuke/畑山 大輔
Subject: [PATCH 1/2] netdump: fix illegal read to already freed buffer
This issue was detecte
Any comments?
Thanks.
HATAYAMA, Daisuke
From: HATAYAMA Daisuke
Sent: Monday, January 4, 2021 14:28
To: crash-utility@redhat.com
Cc: Hatayama, Daisuke/畑山 大輔
Subject: [PATCH v1 0/3] Add valgrind support for the crash's custom memory
This patch set adds va
Is there any comment?
Thanks.
HATAYAMA, Daisuke
From: HATAYAMA Daisuke
Sent: Friday, December 25, 2020 15:48
To: crash-utility@redhat.com
Cc: zhaoqia...@xiaomi.com; Hatayama, Daisuke/畑山 大輔
Subject: [PATCH v2 0/7] zram related changes for zram support of
ts, I think we agree.
Bhupesh, if you have any concerns from Red Hat's view point,
please let us know.
On Mon, Dec 28, 2020 at 10:52 AM d.hatay...@fujitsu.com
wrote:
>
> Hagio san,
>
> > > > I'm now preparing for providing crash-gcore-command and
> > > &g
> static int setup_ikconfig(char *config)
> @@ -10265,8 +10273,8 @@ static int setup_ikconfig(char *config)
> ent++;
>
> if (STRNEQ(ent, "CONFIG_")) {
Another natural fix to me is to extend the condition like:
if (STRNEQ(ent, "CONFIG_") && strstr(ent,
> > Some strange reasons may cause kcore to collect some strange
> > entries of ikconfig, such as CONFIG_SECU+[some hex data] causes
>
> Could you tell me the example of such CONFIG_SEC+[some hex data] that
> causes the val to have NULL. I tried to reproduce but failed.
I guess you mean CONFIG_SE
> Some strange reasons may cause kcore to collect some strange
> entries of ikconfig, such as CONFIG_SECU+[some hex data] causes
Could you tell me the example of such CONFIG_SEC+[some hex data] that
causes the val to have NULL. I tried to reproduce but failed.
> the 'val' to be NULL, and then cra
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
> > > maintaining it in another independent git re
> > 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
> > maintaining it in another independent git repository. Is it possib
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
maintaining it in another independent git repository. Is it possible?
Having in
Hagio-san,
> I've changed the links of crash-gcore-command and ptdump .tar.gz files.
Thanks. I confirmed that I can download both files via
https://crash-utility.github.io/extensions.html directly.
Thanks.
HATAYAMA, Daisuke
From: Kazuhito Hagio
Sent:
Hagio-san,
I noticed the page is redirected to crash-utility/crash-extensions's blob page
when
I click the link.
Could you change the URL associated with the link
from
https://github.com/crash-utility/crash-extensions/blob/master/crash-gcore-command-1.6.1.tar.gz
to
https://github.com/crash-uti
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?
ChangeLog:
- Fix miscalculation of the starting address of the pt_regs
> > it looks that the commit c975008e61121ef8785622c3bc26964da8fe0deb of crash
> > utility
> > has the condition MEMBER_EXISTS("pt_regs", "stackframe").
> This condition can be used to judge before or after 4.7,This change is
> accompanied by the variable stackframe.
>
> > I guess with this pat
> Hi,hatayama
Hi Zhao. Thanks for your prompt response.
>
> I've noticed a issue that has not been fixed in this version,gcore unable to
> parse register correctly in arm64,i found crash-utility is
> fixed,gcore-command can refer to below change:
I see. I'll include fix for this issue into
> > Hagio-san, could you update the description of crash gcore command
> > at https://crash-utility.github.io/extensions.html?
>
> Updated. It seems there is no change on its help page.
> Please let me know if any errors.
I confirmed that it is updated as expected.
Thanks for your help.
Thanks.
> -Original Message-
> > This is the release of crash gcore command, version 1.6.0.
> >
> > This release includes the following 1 new feature and 2 bug fixes.
> >
> > This is tested on the latest kernels on Fedora 33, RHEL8, RHEL7 and
> > RHEL6 on x86_64.
> >
> > Note that ZRAM support is n
tc/selinux/targeted/contexts/files/file_contexts.bin
7ffbf1352000-7ffbf135a000 32768
/usr/lib64/libnl-3.so.200.26.0
7ffbf135a000-7ffbf1369000 00028000 61440
/usr/lib64/libnl-3.so.200.26.0
(thirtsa.drey...@intel.com, d.hatay...@fujitsu.com)
- Fix
> calc_kaslr_offset() already deals with PTI here:
>
>if (st->pti_init_vmlinux || st->kaiser_init_vmlinux)
>pgd = cr3 & ~(CR3_PCID_MASK|PTI_USER_PGTABLE_MASK);
>else
>pgd = cr3 & ~CR3_PCID_MASK;
>
> Thus it's OK to think that the CR3 points at the
> > + */
> > +static int
> > +find_kernel_start(ulong *va, ulong *pa)
> > +{
> > + int i, pgd_idx, pud_idx, pmd_idx, pte_idx;
> > + uint64_t pgd_pte, pud_pte, pmd_pte, pte;
> > +
> > + pgd_idx = pgd_index(__START_KERNEL_map);
> > + pud_idx = pud_index(__START_KERNEL_map);
>
> /*
> + * Find virtual (VA) and physical (PA) addresses of kernel start
> + *
> + * va:
> + * Actual address of the kernel start (_stext) placed
> + * randomly by kaslr feature. To be more accurate,
> + * VA = _stext(from vmlinux) + kaslr_offset
> + *
> + * pa:
> + * Physical address wher
> diff --git a/vmware_vmss.c b/vmware_vmss.c
> index b168f29..8aa0de0 100644
> --- a/vmware_vmss.c
> +++ b/vmware_vmss.c
> @@ -881,6 +881,27 @@ vmware_vmss_get_cr3_idtr(ulong *cr3, ulong *idtr)
> *cr3 = vmss.regs64[0]->cr[3];
> *idtr = vmss.regs64[0]->idtr;
>
> + /*
> +
Lianbo,
> After applied this patch, I got the following compiling error. But when I
> used the 'make lzo' command to compile, it doen't have any problems, which
> automatically added the option '-DLZO' to compiling command.
>
> Did you run into this compiling issue? Or is that the expected result
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 command for now.
Thanks.
HATAYAMA, Daisuke
From: HATAYAMA Daisuke
Sent: Sunday, October 11, 2020 10:34
To: crash-utility@r
> diff --git a/vmware_vmss.c b/vmware_vmss.c
> index b168f29..8aa0de0 100644
> --- a/vmware_vmss.c
> +++ b/vmware_vmss.c
> @@ -881,6 +881,27 @@ vmware_vmss_get_cr3_idtr(ulong *cr3, ulong *idtr)
> *cr3 = vmss.regs64[0]->cr[3];
> *idtr = vmss.regs64[0]->idtr;
>
> + /*
> +
Here are tiny script and program I made to test the zram feature:
https://github.com/d-hatayama/some_stuff_for_crash_zram_devel
This may help your reviewing.
Thanks.
HATAYAMA, Daisuke
From: HATAYAMA Daisuke
Sent: Sunday, October 11, 2020 10:34
To:
> diff --git a/crash.8 b/crash.8
> index 136ae78..5020ce1 100644
> --- a/crash.8
> +++ b/crash.8
> @@ -21,8 +21,9 @@ core dump has been created by the
> .I LKCD,
> .I kdump,
> .I xendump
> -or
> .I kvmdump
> +or
> +.I VMware
> facilities. It is loosely based on the SVR4 UNIX crash
Good cat
> diff --git a/crash.8 b/crash.8
> index 136ae78..783fdf7 100644
> --- a/crash.8
> +++ b/crash.8
> @@ -116,6 +116,12 @@ or
> .I kvmdump
> facilities.
>
> +The
> +.B crash
> +utility is able to process VMware VM memory dump generated by VM suspend
> +or guest core dump. In that case, .vmss or .gue
> I don't know such usage of vmcore-related files from this message.
I meant vmware-related, just for in case...
Thanks.
HATAYAMA, Daisuke
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
Alexey,
> How to use: $ crash /path/to/debug_file.guest vmlinux
> Companion debug_file.vmem must be present in the same folder as
Please add this kind of explanation in man 8 crash, because
> debug_file.guest. Otherwise crash will shot a message:
> vmw: Open the companion vmem file: /path/to/de
> How to use: $ crash debug.guest vmlinux
> debug.vmem must be present in the same folder as debug.guest.
This looks special handling.
I think users need to learn that via crash's message or documentation.
Thanks.
HATAYAMA, Daisuke
--
Crash-utility mailing list
Crash-utility@redhat.com
https:
Lianbo,
Sorry for the delayed response.
Thanks for your report and this patch.
In addition to this patch, it's also necessary to modify ioperm_active() and
ioperm_get() accordingly,
without which, note information of NT_IOPERM fails to be collected.
I'll do the additional fix based on your pat
> 在 2020年09月01日 16:06, d.hatay...@fujitsu.com 写道:
> >> 在 2020年08月31日 12:19, d.hatay...@fujitsu.com 写道:
> >>> Lianbo,
...snip...
> >> BTW: Is that possible to maintain the source code instead of the tarball?
> >> Could it
> >> avoid releasing fr
> 在 2020年08月31日 12:19, d.hatay...@fujitsu.com 写道:
> > Lianbo,
> >
> >> Recently, I'm trying to add the crash extensions to Fedora, and the gcore
> >> reports
> >> an error, which blocks my progress. So, this issue needs to be fixed in
> >>
Lianbo,
> Recently, I'm trying to add the crash extensions to Fedora, and the gcore
> reports
> an error, which blocks my progress. So, this issue needs to be fixed in
> upstream
> firstly.
I see. But actually, I'm testing crash-gcore-command mainly on RHEL
releases and not so frequently on ups
Lianbo, Hagio,
Yes. I'll review this patch. Wait for a while.
Thanks.
HATAYAMA, Daisuke
From: crash-utility-boun...@redhat.com on
behalf of HAGIO KAZUHITO(萩尾 一仁)
Sent: Friday, August 28, 2020 17:36
To: Bhupesh Sharma; Lianbo Jiang
Cc: Discussion list
> 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?
Bhupesh, Lianbo. Do you have any comments?
Thanks.
HATAYAMA, Daisuke
--
Crash-utility mailing list
Crash
> There are a few slight comments, but otherwise the series looks good to me
> and easy to review. It was helpful, thanks!
>
> Acked-by: Kazuhito Hagio
>
> Lianbo, Bhupesh, can we have another ack?
>
> > > And we'd like to put tags such as Signed-off-by, Reported-by, etc. on
> > > commit
>
> diff --git a/sadump.c b/sadump.c
> > index 35f7cf0..85b4a09 100644
> > --- a/sadump.c
> > +++ b/sadump.c
> > @@ -1666,21 +1666,24 @@ get_sadump_smram_cpu_state_any(struct
> > sadump_smram_cpu_state *smram)
> > {
> > ulong offset;
> > struct sadump_header *sh = sd->dump_header;
> >
> > diff --git a/symbols.c b/symbols.c
> > index b9de4a1..fa46e91 100644
> > --- a/symbols.c
> > +++ b/symbols.c
> > @@ -12692,20 +12692,25 @@ numeric_forward(const void *P_x, const void *P_y)
> > else if (STREQ(y->name, "idt_table"))
> > st->idt_table_vmlinu
Haigo-san,
Could you review this patch set?
差出人: HATAYAMA Daisuke
送信日時: 2020年7月9日 21:11
宛先: k-hagio...@nec.com; crash-utility@redhat.com
CC: Hatayama, Daisuke/畑山 大輔
件名: [PATCH 0/4] sadump, kaslr: fix failure of calculating kaslr_offset due to
an sadump f
Hi,
> -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
Hi,
I put some stuff I used in developing the patch set.
Please use them if you think them helpful for reviewing.
https://github.com/d-hatayama/some_stuff_for_crash_zram_devel
差出人: HATAYAMA Daisuke
送信日時: 2020年5月27日 13:59
宛先: crash-utility@redhat.com
CC:
Hagio-san, Bhupesh,
(Sorry for delayed response because I had one week vacation last week...)
> > -Original Message-
> > - Original Message -
> > > Dave,
> > >
> > > > Initially Kazuhito will primarily be handling upstream github duties,
> > > > while Lianbo and Bhupesh will be ha
Dave,
(Sorry for delayed response because I had one week vacation last week...)
> - Original Message -
> > Dave,
> >
> > > Initially Kazuhito will primarily be handling upstream github duties,
> > > while Lianbo and Bhupesh will be handling Fedora, CentOS stream, and
> > > RHEL maintenanc
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
> patches posted on this mailing list. Please welcome them in their
> new roles
Hi,
Hi,
I think gcore or other client,no need to understand what is zram and just call
readmem to get the data.so i encapsulate try_zram_decompress to readmem,gcore
just calling readmem can get right data.It will have better encapsulation,If
one day the kernel provides other ram swap,Do we
Hi,
Hi,Hatayama
Since zram page not a existing page,so we can't use vtop find exactly physical
address,so gcore have to make a little change for this.gcore patch i've
already sent in previous mail
Please don't remove uvtop_quiet(), which is necessary. The reason is to avoid
some bug in cra
Zhao,
I don't find latest patch for gcore command, but looking at the commit
b12bdd36cf7caad24957c0b8c030001321ab2df4 in crash utility,
try_zram_decompress() is called after uvtop() in the final design,
not uvtop() being replaced by readmem(UVADDR), which can more easilly be
into the gcore source
; x230x704cf551c0 482327482816
> x240x7fff 2147483647
> x250x704d0aa020 482328879136
> x260x704cfc8840 482327955520
> x27 0x704407b8 1883506616
> x280x70435dc8 1883463112
> x290x7fdb6d90f0 549142
Zhan,
It looks to me that
0002-gcore-ARM-ARM64-reserved-8-16-byte-in-the-top-of-sta.patch is independent
of the ZRAM support. Without the patch, how does gcore behave? Fai or succeed?
If gcore fails, could you
show me a log indicating how gcore command fails?
> -Original Message-
> From
Dave, Zhao,
> -Original Message-
> From: Dave Anderson
> Sent: Tuesday, March 31, 2020 10:52 PM
> To: Discussion list for crash utility usage, maintenance and development
>
> Cc: d hatayama ; Hatayama, Daisuke/畑山 大輔
>
> Subject: Re: [Crash-utility] zram decompress support for gcore/cr
Hi Dave,
The attached file is updated extension module ptdump v1.0.7.
Please replace old one in extension site [1] with this tarball.
Changelog:
- ptdump: fix build warning: warning: this ‘if’ clause does not guard
- ptdump: fix failure: ptdump: invalid size request: 0 type: "read page for
write
This is the release of crash gcore command, version 1.5.1.
This release includes the following 2 bug fixes.
ChangeLog:
- Fix the invalid structure member failure of
thread_struct_fpsimd_state caused by the commit
65896545b69ffaac947c12e11d3dcc57fd1fb772 merged at v4.17-rc2
("arm64:
Masa,
> -Original Message-
> From: Masayoshi Mizuma [mailto:msys.miz...@gmail.com]
> Sent: Monday, June 24, 2019 9:10 AM
..
> From: Masayoshi Mizuma
>
> On 4.19 and newer kernel, gcore command fails as following:
>
> ===
>
Dave,
> -Original Message-
...
> Thanks Masa, the patch looks good.
>
> And Daisuke, when you update crash-gcore-command package, please also
> include the aarch64 patch we discussed last December:
>
> --- crash-gcore-command-1.3.1/gcore.c.orig
> +++ crash-gcore-command-1.3.1/gcore.c
> @
70 matches
Mail list logo
