Re: [Crash-utility] crash does not work with last fedora kernels?
by lijiang
>
> 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:
> https://src.fedoraproject.org/rpms/kernel/pull-request/48
>
> Once crash gdb is upgraded, the DWARF5 could be enabled again in Fedora
kernel.
>
> BTW: that is a temporary branch, still under tests and it has not been
announced yet.
>
> Lianbo,
> Please STOP replying to the digest, but reply properly on the
> appropriate email thread.
> I've been involved in a lot of open source projects over the past 15
years,
> and you're the only one I've ever seen that replies to a digest, not the
> appropriate email thread.
Good suggestions, David.
I remember that you reminded me about this issue before this time. But
recently my email system switched to Gmail, and made a mistake again. I'm
trying to get used to the Gmail
system.
But anyway, I hope that my last reply answered your questions.
Thanks.
Lianbo
3 years, 3 months
Re: [Crash-utility] crash does not work with last fedora kernels?
by lijiang
> 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 regression issue, which may be caused by the following
patch:
a3ea92bcae1f ("Fix for the tab completion output issues")
Would you mind reverting the above patch and trying it again?
Thanks.
Lianbo
> bt: invalid input: "jne"
> bt: invalid input: "mov"
> bt: invalid input: "movl"
> bt: invalid input: "jne"
> bt: invalid input: "jne"
> bt: invalid input: "jne"
> bt: invalid input: "rep"
> bt: invalid input: "je"
> bt: invalid input: "je"
> bt: invalid input: "je"
> bt: invalid input: "call"
> bt: invalid input: "call"
> bt: invalid input: "jne"
> bt: invalid input: "call"
> bt: invalid input: "call"
> bt: invalid input: "movl"
> bt: invalid input: "mov"
> bt: invalid input: "jne"
> bt: invalid input: "mov"
> bt: invalid input: "je"
> bt: invalid input: "call"
3 years, 3 months
Re: [Crash-utility] Crash-utility Digest, Vol 190, Issue 20
by lijiang
>
> On 7/28/21, 11:14 AM, "crash-utility-bounces(a)redhat.com on behalf of
> David Wysochanski" <crash-utility-bounces(a)redhat.com on behalf of
> dwysocha(a)redhat.com> wrote:
>
> On Wed, Apr 28, 2021 at 8:54 AM lijiang <lijiang(a)redhat.com>
> wrote:
> >
> > ? 2021?04?26? 19:17, crash-utility-request(a)redhat.com ??:
> > > Message: 3
> > > Date: Mon, 26 Apr 2021 11:27:40 +0300
> > > From: Vasily Averin <vvs(a)virtuozzo.com>
> > > To: crash-utility(a)redhat.com
> > > Subject: [Crash-utility] crash does not work with last fedora
> kernels?
> > > Message-ID: <
> 8f8782a9-3da6-5d3c-c509-8b8ec8a30957(a)virtuozzo.com>
> > > Content-Type: text/plain; charset=utf-8
> > >
> > > It looks like Fedora kernels uses gcc11 and generates
> debuginfo in DWARF 5 format.
> > >
> > > [root@localhost ~]# rpm -q crash
> > > crash-7.2.9-5.fc35.x86_64
> > > [root@localhost ~]# uname -a
> > > Linux localhost.localdomain 5.11.12-300.fc34.x86_64 #1 SMP Wed
> Apr 7 16:31:13 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
> > >
> > >
> > > [root@localhost ~]# crash -1
> > > Dwarf Error: wrong version in compilation unit header (is 5,
> should be 2, 3, or 4) [in module
> /usr/lib/debug/usr/lib/modules/5.11.12-300.fc34.x86_64/vmlinux]
> > > crash: gdb_session_init: pulling in debug data by accessing
> init_mm.mmap
> > > Dwarf Error: wrong version in compilation unit header (is 5,
> should be 2, 3, or 4) [in module
> /usr/lib/debug/usr/lib/modules/5.11.12-300.fc34.x86_64/vmlinux]
> > >
> > > crash:
> /usr/lib/debug/lib/modules/5.11.12-300.fc34.x86_64/vmlinux: no debugging
> data available
> > >
> > > [root@localhost ~]# ls -al
> /usr/lib/debug/lib/modules/5.11.12-300.fc34.x86_64/vmlinux
> > > -rwxr-xr-x. 1 root root 679679112 Apr 7 20:14
> /usr/lib/debug/lib/modules/5.11.12-300.fc34.x86_64/vmlinux
> > > [root@localhost ~]# rpm -qf
> /usr/lib/debug/lib/modules/5.11.12-300.fc34.x86_64/vmlinux
> > > kernel-debuginfo-5.11.12-300.fc34.x86_64
> > >
> > > NB: last fc35 does not work too.
> > >
> >
> > Thank you for reporting this issue, Vasily.
> >
> > The DWARF-5 caused this failure. I will have a look and try to
> handle this issue later.
> >
> > Thanks.
> > Lianbo
> >
>
> What's the status of this issue? Is this due to needing updated
> embedded gdb or something else?
>
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:
https://src.fedoraproject.org/rpms/kernel/pull-request/48
Once crash gdb is upgraded, the DWARF5 could be enabled again in Fedora
kernel.
BTW: that is a temporary branch, still under tests and it has not been
announced yet.
Thanks.
Lianbo
3 years, 4 months
Re: [Crash-utility] crash does not work with last fedora kernels?
by lijiang
在 2021年04月26日 19:17, crash-utility-request(a)redhat.com 写道:
> Message: 3
> Date: Mon, 26 Apr 2021 11:27:40 +0300
> From: Vasily Averin <vvs(a)virtuozzo.com>
> To: crash-utility(a)redhat.com
> Subject: [Crash-utility] crash does not work with last fedora kernels?
> Message-ID: <8f8782a9-3da6-5d3c-c509-8b8ec8a30957(a)virtuozzo.com>
> Content-Type: text/plain; charset=utf-8
>
> It looks like Fedora kernels uses gcc11 and generates debuginfo in DWARF 5 format.
>
> [root@localhost ~]# rpm -q crash
> crash-7.2.9-5.fc35.x86_64
> [root@localhost ~]# uname -a
> Linux localhost.localdomain 5.11.12-300.fc34.x86_64 #1 SMP Wed Apr 7 16:31:13 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
>
>
> [root@localhost ~]# crash -1
> Dwarf Error: wrong version in compilation unit header (is 5, should be 2, 3, or 4) [in module /usr/lib/debug/usr/lib/modules/5.11.12-300.fc34.x86_64/vmlinux]
> crash: gdb_session_init: pulling in debug data by accessing init_mm.mmap
> Dwarf Error: wrong version in compilation unit header (is 5, should be 2, 3, or 4) [in module /usr/lib/debug/usr/lib/modules/5.11.12-300.fc34.x86_64/vmlinux]
>
> crash: /usr/lib/debug/lib/modules/5.11.12-300.fc34.x86_64/vmlinux: no debugging data available
>
> [root@localhost ~]# ls -al /usr/lib/debug/lib/modules/5.11.12-300.fc34.x86_64/vmlinux
> -rwxr-xr-x. 1 root root 679679112 Apr 7 20:14 /usr/lib/debug/lib/modules/5.11.12-300.fc34.x86_64/vmlinux
> [root@localhost ~]# rpm -qf /usr/lib/debug/lib/modules/5.11.12-300.fc34.x86_64/vmlinux
> kernel-debuginfo-5.11.12-300.fc34.x86_64
>
> NB: last fc35 does not work too.
>
Thank you for reporting this issue, Vasily.
The DWARF-5 caused this failure. I will have a look and try to handle this issue later.
Thanks.
Lianbo
> Thank you,
> Vasily Averin
3 years, 4 months
[PATCH v2 0/5] Improve handling of incomplete dumps
by Roman Bolshakov
Hi all,
makedumpfile may produce an incomplete dump if interrupted early or in
case if an unrecoverable I/O error happens during the execution of
makedumpfile. As of now crash begins analysis of such incomplete dump
and fails in some misleading way.
The series helps crash to avoid going too far with incomplete dumps
while provides means to localize how much data is lost in the core.
Changes since v1 (https://listman.redhat.com/archives/crash-utility/2021-June/msg00009.html):
- Fixed stale comments (Lianbo)
- Enabled --zero_excluded for ELF dumps (Kazu)
- Dropped dd->total_valid_pages in the second patch (which became patch
3 in the series) and instead introduced dd->max_sect_len to access
total valid pages from the last bucket in dd->valid_pages array.
- Added an explicit warning for incomplete compressed kdumps.
Thanks,
Roman
Roman Bolshakov (5):
diskdump: Fail readmem() early if dump is incomplete
netdump: Permit --zero_excluded for incomplete ELF dumps
diskdump: Print total number of dumpable pages
diskdump: Introduce read_pd()
diskdump: Warn on incomplete dumps
defs.h | 1 +
diskdump.c | 123 ++++++++++++++++++++++++++++++++++++++++++++++-------
memory.c | 7 +++
netdump.c | 5 +--
4 files changed, 117 insertions(+), 19 deletions(-)
--
2.32.0
3 years, 4 months
Re: [Crash-utility] [PATCH v2] kmem: Add support to -S option to specify a range of CPU-specific slab data
by lijiang
> Date: Tue, 13 Jul 2021 14:24:49 +0100
> From: Aaron Tomlin <atomlin(a)redhat.com>
> To: crash-utility(a)redhat.com
> Cc: k-haio-ab(a)nec.com
> Subject: [Crash-utility] [PATCH v2] kmem: Add support to -S option to
> specify a range of CPU-specific slab data
> Message-ID: <20210713132449.2843627-1-atomlin(a)redhat.com>
> Content-Type: text/plain; charset="US-ASCII"
>
> With this patch, it is now possible for one to explicitly specify a range
> of CPU-specific slab data to list. For example:
>
> Note: This is only applicable to a Linux kernel with Kconfig
> CONFIG_SLUB enabled. The optional argument GNU extension
> for getopt(3) is utilised; and, the CPU range must be
> specified as expected
>
> crash> kmem -S=1,4 kmalloc-512
> CACHE OBJSIZE ALLOCATED TOTAL SLABS SSIZE NAME
> ffff8d3f07c06c00 512 1916 3680 115 16k kmalloc-512
> CPU 1 KMEM_CACHE_CPU:
> ffff8d461fa6f140
> CPU 1 SLAB:
> SLAB MEMORY NODE TOTAL ALLOCATED FREE
> fffff540df7c4000 ffff8d45df100000 0 32 8 24
> FREE / [ALLOCATED]
> ffff8d45df100000 (cpu 1 cache)
> [ffff8d45df100200]
> ffff8d45df100400 (cpu 1 cache)
> [ffff8d45df100600]
> ffff8d45df100800 (cpu 1 cache)
> ffff8d45df100a00 (cpu 1 cache)
> ffff8d45df100c00 (cpu 1 cache)
> ffff8d45df100e00 (cpu 1 cache)
> ffff8d45df101000 (cpu 1 cache)
> [ffff8d45df101200]
> ...skipped ...
> CPU 4 KMEM_CACHE_CPU:
> ffff8d461fb2f140
> CPU 4 SLAB:
> SLAB MEMORY NODE TOTAL ALLOCATED FREE
> fffff540dfde3800 ffff8d45f78e0000 0 32 8 24
> FREE / [ALLOCATED]
> [ffff8d45f78e0000]
> ffff8d45f78e0200 (cpu 4 cache)
> ffff8d45f78e0400 (cpu 4 cache)
> [ffff8d45f78e0600]
> ffff8d45f78e0800 (cpu 4 cache)
> ffff8d45f78e0a00 (cpu 4 cache)
> ffff8d45f78e0c00 (cpu 4 cache)
> ffff8d45f78e0e00 (cpu 4 cache)
> ffff8d45f78e1000 (cpu 4 cache)
> ffff8d45f78e1200 (cpu 4 cache)
> ffff8d45f78e1400 (cpu 4 cache)
> [ffff8d45f78e1600]
> ...skipped ...
>
> Signed-off-by: Aaron Tomlin <atomlin(a)redhat.com>
> ---
> Changes since v1:
>
> - Do not explicitly exclude an offline CPU
> as this is handled via hide_offline_cpu()
> logic (Kazu)
>
> ---
> help.c | 5 ++++-
> memory.c | 41 ++++++++++++++++++++++++++++++++++++++---
> 2 files changed, 42 insertions(+), 4 deletions(-)
>
> diff --git a/help.c b/help.c
> index 99be7cb..6c262a3 100644
> --- a/help.c
> +++ b/help.c
> @@ -6601,7 +6601,7 @@ char *help_kmem[] = {
> "kmem",
> "kernel memory",
> "[-f|-F|-c|-C|-i|-v|-V|-n|-z|-o|-h] [-p | -m member[,member]]\n"
> -" [[-s|-S|-r] [slab] [-I slab[,slab]]] [-g [flags]] [[-P] address]]",
> +" [[-s|-S|-S=cpu[s]|-r] [slab] [-I slab[,slab]]] [-g [flags]] [[-P] address]]",
> " This command displays information about the use of kernel memory.\n",
> " -f displays the contents of the system free memory headers.",
> " also verifies that the page count equals nr_free_pages.",
> @@ -6649,6 +6649,9 @@ char *help_kmem[] = {
> " slab data for each per-cpu slab is displayed, along with the",
> " address of each kmem_cache_node, its count of full and partial",
> " slabs, and a list of all tracked slabs.",
> +" Note: one can specify the per-cpu slab data to be displayed;",
> +" the cpu[s] can be given as \"1,3,5\", \"1-3\", \"1,3,5-7,10\",",
> +" \"all\", or \"a\" (shortcut for \"all\").",
> " -r displays the accumulated basic kmalloc() slab data of each",
> " root slab cache and its children. The kernel must contain the",
> " \"slab_root_caches\" list_head. (currently only available if",
> diff --git a/memory.c b/memory.c
> index cbe90ee..d59784c 100644
> --- a/memory.c
> +++ b/memory.c
> @@ -48,6 +48,7 @@ struct meminfo { /* general purpose memory information structure */
> int slab_offset;
> char *reqname;
> char *curname;
> + ulong *spec_cpumask;
> ulong *addrlist;
> int *kmem_bufctl;
> ulong *cpudata[NR_CPUS];
> @@ -4851,10 +4852,13 @@ cmd_kmem(void)
> struct meminfo meminfo;
> ulonglong value[MAXARGS];
> char buf[BUFSIZE];
> + char arg_buf[BUFSIZE];
> char *p1;
> - int spec_addr, escape;
> + ulong *cpus;
> + int spec_addr, escape, choose_cpu;
>
> - spec_addr = 0;
> + cpus = NULL;
> + spec_addr = choose_cpu = 0;
> sflag = Sflag = pflag = fflag = Fflag = Pflag = zflag = oflag = 0;
> vflag = Cflag = cflag = iflag = nflag = lflag = Lflag = Vflag = 0;
> gflag = hflag = rflag = 0;
> @@ -4863,7 +4867,7 @@ cmd_kmem(void)
> BZERO(&value[0], sizeof(ulonglong)*MAXARGS);
> pc->curcmd_flags &= ~HEADER_PRINTED;
>
> - while ((c = getopt(argcnt, args, "gI:sSrFfm:pvczCinl:L:PVoh")) != EOF) {
> + while ((c = getopt(argcnt, args, "gI:sS::rFfm:pvczCinl:L:PVoh")) != EOF) {
> switch(c)
> {
> case 'V':
> @@ -4903,6 +4907,33 @@ cmd_kmem(void)
> break;
>
> case 'S':
> + if (choose_cpu)
> + error(FATAL, "only one -S option allowed\n");
> + /* Use the GNU extension with getopt(3) ... */
> + if (optarg) {
> + if (!(vt->flags & KMALLOC_SLUB))
> + error(FATAL,
> + "can only use -S=cpu(s) with a kernel \n"
> + "that is built with CONFIG_SLUB support.\n");
> + if (optarg[0] != '=')
> + error(FATAL,
> + "CPU-specific slab data to be displayed "
> + "must be written as expected only e.g. -S=1,45.\n");
> + /* Skip = ... */
> + optarg++;
> +
> + choose_cpu = 1;
> + BZERO(arg_buf, BUFSIZE);
> + strcpy(arg_buf, optarg);
> +
> + cpus = get_cpumask_buf();
> + make_cpumask(arg_buf, cpus, FAULT_ON_ERROR, NULL);
> + meminfo.spec_cpumask = cpus;
> +
> + for (i = 0; i < kt->cpus; i++)
> + if (NUM_IN_BITMAP(cpus, i) && check_offline_cpu(i))
> + error(INFO, "CPU %d is OFFLINE.\n", i);
> + }
> Sflag = 1; sflag = rflag = 0;
> break;
>
> @@ -5185,6 +5216,8 @@ cmd_kmem(void)
> meminfo.flags = VERBOSE;
> vt->dump_kmem_cache(&meminfo);
> }
> + if (choose_cpu)
> + FREEBUF(cpus);
> }
>
> if (vflag == 1)
> @@ -19083,6 +19116,8 @@ do_kmem_cache_slub(struct meminfo *si)
> per_cpu = (ulong *)GETBUF(sizeof(ulong) * vt->numnodes);
>
> for (i = 0; i < kt->cpus; i++) {
> + if (si->spec_cpumask && !NUM_IN_BITMAP(si->spec_cpumask, i))
> + continue;
> if (hide_offline_cpu(i)) {
> fprintf(fp, "CPU %d [OFFLINE]\n", i);
> continue;
> --
> 2.31.1
For the v2 with Kazu's correction:
Acked-by: Lianbo Jiang <lijiang(a)redhat.com>
3 years, 4 months
Crash utility with RT patchset
by Abhishek Shah
Hi All,
I was wondering if there is any change required in either crash utility or
RT Linux to make use of crash utility to analyze ramdump with RT Linux.
I am using crash 7.3.0++ and Linux - 5.4.61-rt37 on arm64 target.
I see the below error:
../crash DDR0.BIN@0x80000000,DDR1.BIN(a)0x100000000 vmlinux
--machdep vabits_actual=39 --kaslr 0x2ff9600000
......
crash: invalid kernel virtual address: fffffff791ff5a5f type: "64-bit KVADDR"
Regards,
Abhishek
3 years, 4 months
[PATCH v2] kmem: Add support to -S option to specify a range of CPU-specific slab data
by Aaron Tomlin
With this patch, it is now possible for one to explicitly specify a range
of CPU-specific slab data to list. For example:
Note: This is only applicable to a Linux kernel with Kconfig
CONFIG_SLUB enabled. The optional argument GNU extension
for getopt(3) is utilised; and, the CPU range must be
specified as expected
crash> kmem -S=1,4 kmalloc-512
CACHE OBJSIZE ALLOCATED TOTAL SLABS SSIZE NAME
ffff8d3f07c06c00 512 1916 3680 115 16k kmalloc-512
CPU 1 KMEM_CACHE_CPU:
ffff8d461fa6f140
CPU 1 SLAB:
SLAB MEMORY NODE TOTAL ALLOCATED FREE
fffff540df7c4000 ffff8d45df100000 0 32 8 24
FREE / [ALLOCATED]
ffff8d45df100000 (cpu 1 cache)
[ffff8d45df100200]
ffff8d45df100400 (cpu 1 cache)
[ffff8d45df100600]
ffff8d45df100800 (cpu 1 cache)
ffff8d45df100a00 (cpu 1 cache)
ffff8d45df100c00 (cpu 1 cache)
ffff8d45df100e00 (cpu 1 cache)
ffff8d45df101000 (cpu 1 cache)
[ffff8d45df101200]
...skipped ...
CPU 4 KMEM_CACHE_CPU:
ffff8d461fb2f140
CPU 4 SLAB:
SLAB MEMORY NODE TOTAL ALLOCATED FREE
fffff540dfde3800 ffff8d45f78e0000 0 32 8 24
FREE / [ALLOCATED]
[ffff8d45f78e0000]
ffff8d45f78e0200 (cpu 4 cache)
ffff8d45f78e0400 (cpu 4 cache)
[ffff8d45f78e0600]
ffff8d45f78e0800 (cpu 4 cache)
ffff8d45f78e0a00 (cpu 4 cache)
ffff8d45f78e0c00 (cpu 4 cache)
ffff8d45f78e0e00 (cpu 4 cache)
ffff8d45f78e1000 (cpu 4 cache)
ffff8d45f78e1200 (cpu 4 cache)
ffff8d45f78e1400 (cpu 4 cache)
[ffff8d45f78e1600]
...skipped ...
Signed-off-by: Aaron Tomlin <atomlin(a)redhat.com>
---
Changes since v1:
- Do not explicitly exclude an offline CPU
as this is handled via hide_offline_cpu()
logic (Kazu)
---
help.c | 5 ++++-
memory.c | 41 ++++++++++++++++++++++++++++++++++++++---
2 files changed, 42 insertions(+), 4 deletions(-)
diff --git a/help.c b/help.c
index 99be7cb..6c262a3 100644
--- a/help.c
+++ b/help.c
@@ -6601,7 +6601,7 @@ char *help_kmem[] = {
"kmem",
"kernel memory",
"[-f|-F|-c|-C|-i|-v|-V|-n|-z|-o|-h] [-p | -m member[,member]]\n"
-" [[-s|-S|-r] [slab] [-I slab[,slab]]] [-g [flags]] [[-P] address]]",
+" [[-s|-S|-S=cpu[s]|-r] [slab] [-I slab[,slab]]] [-g [flags]] [[-P] address]]",
" This command displays information about the use of kernel memory.\n",
" -f displays the contents of the system free memory headers.",
" also verifies that the page count equals nr_free_pages.",
@@ -6649,6 +6649,9 @@ char *help_kmem[] = {
" slab data for each per-cpu slab is displayed, along with the",
" address of each kmem_cache_node, its count of full and partial",
" slabs, and a list of all tracked slabs.",
+" Note: one can specify the per-cpu slab data to be displayed;",
+" the cpu[s] can be given as \"1,3,5\", \"1-3\", \"1,3,5-7,10\",",
+" \"all\", or \"a\" (shortcut for \"all\").",
" -r displays the accumulated basic kmalloc() slab data of each",
" root slab cache and its children. The kernel must contain the",
" \"slab_root_caches\" list_head. (currently only available if",
diff --git a/memory.c b/memory.c
index cbe90ee..d59784c 100644
--- a/memory.c
+++ b/memory.c
@@ -48,6 +48,7 @@ struct meminfo { /* general purpose memory information structure */
int slab_offset;
char *reqname;
char *curname;
+ ulong *spec_cpumask;
ulong *addrlist;
int *kmem_bufctl;
ulong *cpudata[NR_CPUS];
@@ -4851,10 +4852,13 @@ cmd_kmem(void)
struct meminfo meminfo;
ulonglong value[MAXARGS];
char buf[BUFSIZE];
+ char arg_buf[BUFSIZE];
char *p1;
- int spec_addr, escape;
+ ulong *cpus;
+ int spec_addr, escape, choose_cpu;
- spec_addr = 0;
+ cpus = NULL;
+ spec_addr = choose_cpu = 0;
sflag = Sflag = pflag = fflag = Fflag = Pflag = zflag = oflag = 0;
vflag = Cflag = cflag = iflag = nflag = lflag = Lflag = Vflag = 0;
gflag = hflag = rflag = 0;
@@ -4863,7 +4867,7 @@ cmd_kmem(void)
BZERO(&value[0], sizeof(ulonglong)*MAXARGS);
pc->curcmd_flags &= ~HEADER_PRINTED;
- while ((c = getopt(argcnt, args, "gI:sSrFfm:pvczCinl:L:PVoh")) != EOF) {
+ while ((c = getopt(argcnt, args, "gI:sS::rFfm:pvczCinl:L:PVoh")) != EOF) {
switch(c)
{
case 'V':
@@ -4903,6 +4907,33 @@ cmd_kmem(void)
break;
case 'S':
+ if (choose_cpu)
+ error(FATAL, "only one -S option allowed\n");
+ /* Use the GNU extension with getopt(3) ... */
+ if (optarg) {
+ if (!(vt->flags & KMALLOC_SLUB))
+ error(FATAL,
+ "can only use -S=cpu(s) with a kernel \n"
+ "that is built with CONFIG_SLUB support.\n");
+ if (optarg[0] != '=')
+ error(FATAL,
+ "CPU-specific slab data to be displayed "
+ "must be written as expected only e.g. -S=1,45.\n");
+ /* Skip = ... */
+ optarg++;
+
+ choose_cpu = 1;
+ BZERO(arg_buf, BUFSIZE);
+ strcpy(arg_buf, optarg);
+
+ cpus = get_cpumask_buf();
+ make_cpumask(arg_buf, cpus, FAULT_ON_ERROR, NULL);
+ meminfo.spec_cpumask = cpus;
+
+ for (i = 0; i < kt->cpus; i++)
+ if (NUM_IN_BITMAP(cpus, i) && check_offline_cpu(i))
+ error(INFO, "CPU %d is OFFLINE.\n", i);
+ }
Sflag = 1; sflag = rflag = 0;
break;
@@ -5185,6 +5216,8 @@ cmd_kmem(void)
meminfo.flags = VERBOSE;
vt->dump_kmem_cache(&meminfo);
}
+ if (choose_cpu)
+ FREEBUF(cpus);
}
if (vflag == 1)
@@ -19083,6 +19116,8 @@ do_kmem_cache_slub(struct meminfo *si)
per_cpu = (ulong *)GETBUF(sizeof(ulong) * vt->numnodes);
for (i = 0; i < kt->cpus; i++) {
+ if (si->spec_cpumask && !NUM_IN_BITMAP(si->spec_cpumask, i))
+ continue;
if (hide_offline_cpu(i)) {
fprintf(fp, "CPU %d [OFFLINE]\n", i);
continue;
--
2.31.1
3 years, 4 months
[PATCH] kmem: Add support to -S option to specify a range of CPU-specific slab data
by Aaron Tomlin
With this patch, it is now possible for one to explicitly specify a range
of CPU-specific slab data to list. For example:
Note: This is only applicable to a Linux kernel with Kconfig
CONFIG_SLUB enabled. The optional argument GNU extension
for getopt(3) is utilised; and, the CPU range must be
specified as expected
crash> kmem -S=1,4 kmalloc-512
CACHE OBJSIZE ALLOCATED TOTAL SLABS SSIZE NAME
ffff8d3f07c06c00 512 1916 3680 115 16k kmalloc-512
CPU 1 KMEM_CACHE_CPU:
ffff8d461fa6f140
CPU 1 SLAB:
SLAB MEMORY NODE TOTAL ALLOCATED FREE
fffff540df7c4000 ffff8d45df100000 0 32 8 24
FREE / [ALLOCATED]
ffff8d45df100000 (cpu 1 cache)
[ffff8d45df100200]
ffff8d45df100400 (cpu 1 cache)
[ffff8d45df100600]
ffff8d45df100800 (cpu 1 cache)
ffff8d45df100a00 (cpu 1 cache)
ffff8d45df100c00 (cpu 1 cache)
ffff8d45df100e00 (cpu 1 cache)
ffff8d45df101000 (cpu 1 cache)
[ffff8d45df101200]
...skipped ...
CPU 4 KMEM_CACHE_CPU:
ffff8d461fb2f140
CPU 4 SLAB:
SLAB MEMORY NODE TOTAL ALLOCATED FREE
fffff540dfde3800 ffff8d45f78e0000 0 32 8 24
FREE / [ALLOCATED]
[ffff8d45f78e0000]
ffff8d45f78e0200 (cpu 4 cache)
ffff8d45f78e0400 (cpu 4 cache)
[ffff8d45f78e0600]
ffff8d45f78e0800 (cpu 4 cache)
ffff8d45f78e0a00 (cpu 4 cache)
ffff8d45f78e0c00 (cpu 4 cache)
ffff8d45f78e0e00 (cpu 4 cache)
ffff8d45f78e1000 (cpu 4 cache)
ffff8d45f78e1200 (cpu 4 cache)
ffff8d45f78e1400 (cpu 4 cache)
[ffff8d45f78e1600]
...skipped ...
Signed-off-by: Aaron Tomlin <atomlin(a)redhat.com>
---
help.c | 5 ++++-
memory.c | 47 +++++++++++++++++++++++++++++++++++++++++++----
2 files changed, 47 insertions(+), 5 deletions(-)
diff --git a/help.c b/help.c
index e0c8408..8d40204 100644
--- a/help.c
+++ b/help.c
@@ -6571,7 +6571,7 @@ char *help_kmem[] = {
"kmem",
"kernel memory",
"[-f|-F|-c|-C|-i|-v|-V|-n|-z|-o|-h] [-p | -m member[,member]]\n"
-" [[-s|-S|-r] [slab] [-I slab[,slab]]] [-g [flags]] [[-P] address]]",
+" [[-s|-S|-S=cpu[s]|-r] [slab] [-I slab[,slab]]] [-g [flags]] [[-P] address]]",
" This command displays information about the use of kernel memory.\n",
" -f displays the contents of the system free memory headers.",
" also verifies that the page count equals nr_free_pages.",
@@ -6616,6 +6616,9 @@ char *help_kmem[] = {
" slab data for each per-cpu slab is displayed, along with the",
" address of each kmem_cache_node, its count of full and partial",
" slabs, and a list of all tracked slabs.",
+" Note: one can specify the per-cpu slab data to be displayed;",
+" the cpu[s] can be given as \"1,3,5\", \"1-3\", \"1,3,5-7,10\",",
+" \"all\", or \"a\" (shortcut for \"all\").",
" -r displays the accumulated basic kmalloc() slab data of each",
" root slab cache and its children. The kernel must contain the",
" \"slab_root_caches\" list_head. (currently only available if",
diff --git a/memory.c b/memory.c
index 8c6bbe4..ef7c3ec 100644
--- a/memory.c
+++ b/memory.c
@@ -47,6 +47,7 @@ struct meminfo { /* general purpose memory information structure */
int slab_offset;
char *reqname;
char *curname;
+ ulong *spec_cpumask;
ulong *addrlist;
int *kmem_bufctl;
ulong *cpudata[NR_CPUS];
@@ -4850,10 +4851,13 @@ cmd_kmem(void)
struct meminfo meminfo;
ulonglong value[MAXARGS];
char buf[BUFSIZE];
+ char arg_buf[BUFSIZE];
char *p1;
- int spec_addr, escape;
+ ulong *cpus;
+ int spec_addr, escape, choose_cpu;
- spec_addr = 0;
+ cpus = NULL;
+ spec_addr = choose_cpu = 0;
sflag = Sflag = pflag = fflag = Fflag = Pflag = zflag = oflag = 0;
vflag = Cflag = cflag = iflag = nflag = lflag = Lflag = Vflag = 0;
gflag = hflag = rflag = 0;
@@ -4862,7 +4866,7 @@ cmd_kmem(void)
BZERO(&value[0], sizeof(ulonglong)*MAXARGS);
pc->curcmd_flags &= ~HEADER_PRINTED;
- while ((c = getopt(argcnt, args, "gI:sSrFfm:pvczCinl:L:PVoh")) != EOF) {
+ while ((c = getopt(argcnt, args, "gI:sS::rFfm:pvczCinl:L:PVoh")) != EOF) {
switch(c)
{
case 'V':
@@ -4902,6 +4906,33 @@ cmd_kmem(void)
break;
case 'S':
+ if (choose_cpu)
+ error(FATAL, "only one -S option allowed\n");
+ /* Use the GNU extension with getopt(3) ... */
+ if (optarg) {
+ if (!(vt->flags & KMALLOC_SLUB))
+ error(FATAL,
+ "can only use -S=cpu(s) with a kernel \n"
+ "that is built with CONFIG_SLUB support.\n");
+ if (optarg[0] != '=')
+ error(FATAL,
+ "CPU-specific slab data to be displayed "
+ "must be written as expected only e.g. -S=1,45.\n");
+ /* Skip = ... */
+ optarg++;
+
+ choose_cpu = 1;
+ BZERO(arg_buf, BUFSIZE);
+ strcpy(arg_buf, optarg);
+
+ cpus = get_cpumask_buf();
+ make_cpumask(arg_buf, cpus, FAULT_ON_ERROR, NULL);
+ meminfo.spec_cpumask = cpus;
+
+ for (i = 0; i < kt->cpus; i++)
+ if (NUM_IN_BITMAP(cpus, i) && check_offline_cpu(i))
+ error(INFO, "CPU %d is OFFLINE.\n", i);
+ }
Sflag = 1; sflag = rflag = 0;
break;
@@ -5184,6 +5215,8 @@ cmd_kmem(void)
meminfo.flags = VERBOSE;
vt->dump_kmem_cache(&meminfo);
}
+ if (choose_cpu)
+ FREEBUF(cpus);
}
if (vflag == 1)
@@ -19079,7 +19112,13 @@ do_kmem_cache_slub(struct meminfo *si)
per_cpu = (ulong *)GETBUF(sizeof(ulong) * vt->numnodes);
for (i = 0; i < kt->cpus; i++) {
- if (hide_offline_cpu(i)) {
+ if (si->spec_cpumask) {
+ if (!(NUM_IN_BITMAP(si->spec_cpumask, i)))
+ continue;
+ else
+ if (check_offline_cpu(i))
+ continue;
+ } else if (hide_offline_cpu(i)) {
fprintf(fp, "CPU %d [OFFLINE]\n", i);
continue;
}
--
2.31.1
3 years, 4 months
Crash utility with RT patchset
by Abhishek Shah
Hi All,
I was wondering if there is any change required in either crash utility or
RT Linux to make use of crash utility to analyze ramdump with RT Linux.
I am using crash 7.3.0++ and Linux - 5.4.61-rt37 on arm64 target.
I see the below error:
../crash DDR0.BIN@0x80000000,DDR1.BIN(a)0x100000000 vmlinux
--machdep vabits_actual=39 --kaslr 0x2ff9600000
......
crash: invalid kernel virtual address: fffffff791ff5a5f type: "64-bit KVADDR"
Regards,
Abhishek
3 years, 4 months
