[PATCH 1/4] Fix gcc-11 compilation warnings on filesys.c
by HAGIO KAZUHITO(萩尾 一仁)
Without the patch, the following gcc-11 compilation warnings are
emitted for filesys.c:
filesys.c: In function 'mount_point':
filesys.c:718:17: warning: 'pclose' called on pointer returned from a mismatched allocation function [-Wmismatched-dealloc]
718 | pclose(mp);
| ^~~~~~~~~~
filesys.c:709:27: note: returned from 'fopen'
709 | if ((mp = fopen(mntfile, "r")) == NULL)
| ^~~~~~~~~~~~~~~~~~~
filesys.c:738:17: warning: 'pclose' called on pointer returned from a mismatched allocation function [-Wmismatched-dealloc]
738 | pclose(mp);
| ^~~~~~~~~~
filesys.c:723:27: note: returned from 'fopen'
723 | if ((mp = fopen(mntfile, "r")) == NULL)
| ^~~~~~~~~~~~~~~~~~~
Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
---
filesys.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/filesys.c b/filesys.c
index 43cbe82..a863f04 100644
--- a/filesys.c
+++ b/filesys.c
@@ -715,7 +715,7 @@ mount_point(char *name)
continue;
found++;
}
- pclose(mp);
+ fclose(mp);
if (!(mount_points = (char **)malloc(sizeof(char *) * found)))
return FALSE;
@@ -735,7 +735,7 @@ mount_point(char *name)
mount_points_gathered++, i++;
}
}
- pclose(mp);
+ fclose(mp);
if (CRASHDEBUG(2))
for (i = 0; i < mount_points_gathered; i++)
--
2.31.1
1 year, 11 months
[PATCH V4 0/5] RISC-V fixups to work with crash tool
by Xianting Tian
I ever sent the patch 1 in the link:
https://patchwork.kernel.org/project/linux-riscv/patch/20220708073150.352...
And patch 2,3 in the link:
https://patchwork.kernel.org/project/linux-riscv/patch/20220714113300.367...
https://patchwork.kernel.org/project/linux-riscv/patch/20220714113300.367...
This patch series just put these patches together, and with two new patch 4, 5.
these five patches are the fixups for machine_kexec, kernel mode PC for vmcore
and improvements for vmcoreinfo and memory layout dump.
The main changes in the five patchs as below,
Patch 1: use __smp_processor_id() instead of smp_processor_id() to cleanup
the console prints.
Patch 2: Add VM layout, va bits, ram base to vmcoreinfo, which can simplify
the development of crash tool as ARM64 already did
(arch/arm64/kernel/crash_core.c).
Patch 3: Add modules to virtual kernel memory layout dump.
Patch 4: Fixup to get correct kernel mode PC for vmcore.
Patch 5: Updates vmcoreinfo.rst.
With these 5 patches(patch 2 is must), crash tool can work well to analyze
a vmcore. The patches for crash tool for RISCV64 is in the link:
https://lore.kernel.org/linux-riscv/20220718025346.411758-1-xianting.tian...
Changes v1 -> v2:
1, remove the patch "Add a fast call path of crash_kexec()" from this series
of patches, as it already applied to riscv git.
https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/commit/?h...
2, add 'Reviewed-by' based on the comments of v1.
Changes v2 -> v3:
use "riscv" instead of "riscv64" in patch 5 subject line.
Changes v3 -> v4:
use "riscv" instead of "riscv64" in the summary of patch 5 subject line.
Xianting Tian (5):
RISC-V: use __smp_processor_id() instead of smp_processor_id()
RISC-V: Add arch_crash_save_vmcoreinfo support
riscv: Add modules to virtual kernel memory layout dump
RISC-V: Fixup getting correct current pc
riscv: crash_core: Export kernel vm layout, phys_ram_base
.../admin-guide/kdump/vmcoreinfo.rst | 31 +++++++++++++++++++
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/crash_core.c | 29 +++++++++++++++++
arch/riscv/kernel/crash_save_regs.S | 2 +-
arch/riscv/kernel/machine_kexec.c | 2 +-
arch/riscv/mm/init.c | 4 +++
6 files changed, 67 insertions(+), 2 deletions(-)
create mode 100644 arch/riscv/kernel/crash_core.c
--
2.17.1
1 year, 11 months
[RESEND PATCH V2 0/5] Fixups to work with crash tool
by Xianting Tian
I ever sent the patch 1 in the link:
https://patchwork.kernel.org/project/linux-riscv/patch/20220708073150.352...
And patch 2,3 in the link:
https://patchwork.kernel.org/project/linux-riscv/patch/20220714113300.367...
https://patchwork.kernel.org/project/linux-riscv/patch/20220714113300.367...
This patch series just put these patches together, and with two new patch 4, 5.
these five patches are the fixups for machine_kexec, kernel mode PC for vmcore
and improvements for vmcoreinfo and memory layout dump.
The main changes in the five patchs as below,
Patch 1: use __smp_processor_id() instead of smp_processor_id() to cleanup
the console prints.
Patch 2: Add VM layout, va bits, ram base to vmcoreinfo, which can simplify
the development of crash tool as ARM64 already did
(arch/arm64/kernel/crash_core.c).
Patch 3: Add modules to virtual kernel memory layout dump.
Patch 4: Fixup to get correct kernel mode PC for vmcore.
Patch 5: Updates vmcoreinfo.rst.
With these 5 patches(patch 2 is must), crash tool can work well to analyze
a vmcore. The patches for crash tool for RISCV64 is in the link:
https://lore.kernel.org/linux-riscv/20220718025346.411758-1-xianting.tian...
Changes v1 -> v2:
1, remove the patch "Add a fast call path of crash_kexec()" from this series
of patches, as it already applied to riscv git.
https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/commit/?h...
2, add 'Reviewed-by' based on the comments of v1.
Xianting Tian (5):
RISC-V: use __smp_processor_id() instead of smp_processor_id()
RISC-V: Add arch_crash_save_vmcoreinfo support
riscv: Add modules to virtual kernel memory layout dump
RISC-V: Fixup getting correct current pc
riscv64: crash_core: Export kernel vm layout, phys_ram_base
.../admin-guide/kdump/vmcoreinfo.rst | 31 +++++++++++++++++++
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/crash_core.c | 29 +++++++++++++++++
arch/riscv/kernel/crash_save_regs.S | 2 +-
arch/riscv/kernel/machine_kexec.c | 2 +-
arch/riscv/mm/init.c | 4 +++
6 files changed, 67 insertions(+), 2 deletions(-)
create mode 100644 arch/riscv/kernel/crash_core.c
--
2.17.1
1 year, 11 months
Re: [Crash-utility] crash: read error on type: "memory section root table"
by HAGIO KAZUHITO(萩尾 一仁)
-----Original Message-----
> Hello,
>
> Sorry to cross post on both ML, I'm not sure which one would be the most suitable.
>
> Issue on analysis with crash-7.3.1 on a Centos 8 machine:
> crash: read error: kernel virtual address: ffff8f4fff7fc000 type: "memory section root table"
>
> Crash machine has a Rocky Linux 8.5 based kernel with following config options:
> - CONFIG_RANDOMIZE_BASE=y
> - CONFIG_RANDOMIZE_MEMORY=y
> - CONFIG_SPARSEMEM_MANUAL=y
> - CONFIG_SPARSEMEM=y
> - CONFIG_SPARSEMEM_EXTREME=y
> - CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
> - CONFIG_KEXEC_CORE=y
> - CONFIG_KEXEC=y
> - CONFIG_KEXEC_FILE=y
>
> Kexec-tools package is from Centos Stream repo: kexec-tools-2.0.20-68.el8.2.5ale.x86_64
>
> /proc/vmcore is packaged with :
> /sbin/makedumpfile -D -d 0 -c --message-level 15 /proc/vmcore /tmpd/crashdump-${linux_ver}-${date_time}
>
> At kernel panic, I get:
> Dumping memory to crash partition
> This may take a while, please wait...
> makedumpfile: version 1.7.0 (released on 8 Nov 2021)
> command line: /sbin/makedumpfile -D -d 0 -c --message-level 15 /proc/vmcore /tmpd/crashdump--20220329-1538
>
> sadump: does not have partition header
> sadump: read dump device as unknown format
> sadump: unknown format
> phys_start phys_end virt_start virt_end
> LOAD[ 0] 8000000 9a2c000 ffffffff8a400000 ffffffff8be2c000
> LOAD[ 1] 100000 3b000000 ffff8f4fc0100000 ffff8f4ffb000000
> LOAD[ 2] 3d800000 3e341000 ffff8f4ffd800000 ffff8f4ffe341000
> LOAD[ 3] 3ed7b000 3eee2000 ffff8f4ffed7b000 ffff8f4ffeee2000
> LOAD[ 4] 3f63a000 3f800000 ffff8f4fff63a000 ffff8f4fff800000
> Linux kdump
> VMCOREINFO :
> OSRELEASE=4.18.0-348.12.2.el8_5-ale
> PAGESIZE=4096
> page_size : 4096
> SYMBOL(init_uts_ns)=ffffffff8b653600
> SYMBOL(node_online_map)=ffffffff8b7630a8
> SYMBOL(swapper_pg_dir)=ffffffff8b64c000
> SYMBOL(_stext)=ffffffff8a400000
> SYMBOL(vmap_area_list)=ffffffff8b6a47a0
> SYMBOL(mem_map)=ffffffff8bd25828
> SYMBOL(contig_page_data)=ffffffff8b726600
> SYMBOL(mem_section)=ffff8f4fff7fc000
hm, probably I've never seen a system that has both mem_map and mem_section, but
it looks like makedumpfile works fine.. i.e. recognizes it as SPARSEMEM_EXTREME
correctly.
> LENGTH(mem_section)=2048
> SIZE(mem_section)=16
> OFFSET(mem_section.section_mem_map)=0
> SIZE(page)=64
> SIZE(pglist_data)=5696
> SIZE(zone)=1216
> SIZE(free_area)=72
> SIZE(list_head)=16
> SIZE(nodemask_t)=8
> OFFSET(page.flags)=0
> OFFSET(page._refcount)=52
> OFFSET(page.mapping)=24
> OFFSET(page.lru)=8
> OFFSET(page._mapcount)=48
> OFFSET(page.private)=40
> OFFSET(page.compound_dtor)=16
> OFFSET(page.compound_order)=17
> OFFSET(page.compound_head)=8
> OFFSET(pglist_data.node_zones)=0
> OFFSET(pglist_data.nr_zones)=4944
> OFFSET(pglist_data.node_start_pfn)=4952
> OFFSET(pglist_data.node_spanned_pages)=4968
> OFFSET(pglist_data.node_id)=4976
> OFFSET(zone.free_area)=192
> OFFSET(zone.vm_stat)=1104
> OFFSET(zone.spanned_pages)=96
> OFFSET(free_area.free_list)=0
> OFFSET(list_head.next)=0
> OFFSET(list_head.prev)=8
> OFFSET(vmap_area.va_start)=0
> OFFSET(vmap_area.list)=40
> LENGTH(zone.free_area)=11
> SYMBOL(log_buf)=ffffffff8b67d3c0
> SYMBOL(log_buf_len)=ffffffff8b67d3bc
> SYMBOL(log_first_idx)=ffffffff8bd1a3d8
> SYMBOL(clear_idx)=ffffffff8bd1a3a4
> SYMBOL(log_next_idx)=ffffffff8bd1a3c8
> SIZE(printk_log)=16
> OFFSET(printk_log.ts_nsec)=0
> OFFSET(printk_log.len)=8
> OFFSET(printk_log.text_len)=10
> OFFSET(printk_log.dict_len)=12
> LENGTH(free_area.free_list)=4
> NUMBER(NR_FREE_PAGES)=0
> NUMBER(PG_lru)=5
> NUMBER(PG_private)=12
> NUMBER(PG_swapcache)=9
> NUMBER(PG_swapbacked)=18
> NUMBER(PG_slab)=8
> NUMBER(PG_head_mask)=32768
> NUMBER(PAGE_BUDDY_MAPCOUNT_VALUE)=-129
> NUMBER(HUGETLB_PAGE_DTOR)=2
> NUMBER(PAGE_OFFLINE_MAPCOUNT_VALUE)=-257
> SYMBOL(alcatel_dump_info)=ffffffff8b647000
> NUMBER(phys_base)=-37748736
> SYMBOL(init_top_pgt)=ffffffff8b64c000
> NUMBER(pgtable_l5_enabled)=0
> KERNELOFFSET=9400000
> NUMBER(KERNEL_IMAGE_SIZE)=1073741824
> NUMBER(sme_mask)=0
> CRASHTIME=1648561077
>
> phys_base : fffffffffdc00000 (vmcoreinfo)
>
> max_mapnr : 3f800
> There is enough free memory to be done in one cycle.
>
> Buffer size for the cyclic mode: 65024
> page_offset : ffff8f4fc0000000 (pt_load)
> num of NODEs : 1
> Memory type : SPARSEMEM_EX
>
> mem_map pfn_start pfn_end
> mem_map[ 0] ffff8f4ffa000000 0 8000
> mem_map[ 1] ffff8f4ffa200000 8000 10000
> mem_map[ 2] ffff8f4ffa400000 10000 18000
> mem_map[ 3] ffff8f4ffa600000 18000 20000
> mem_map[ 4] ffff8f4ffa800000 20000 28000
> mem_map[ 5] ffff8f4ffaa00000 28000 30000
> mem_map[ 6] ffff8f4ffac00000 30000 38000
> mem_map[ 7] ffff8f4ffae00000 38000 3f800
> mmap() is available on the kernel.
> Copying data : [100.0 %] | eta: 0s
> Writing erase info...
> offset_eraseinfo: ca157f3, size_eraseinfo: 0
>
> The dumpfile is saved to /tmpd/crashdump--20220329-1538.
>
> makedumpfile Completed.
> Rebooting the system...
>
> And latest logs from a 'crash -d 7' command are:
> <.>
> kernel NR_CPUS: 2
> <readmem: ffffffff8bd25820, KVADDR, "high_memory", 8, (FOE), 55e05ecb3608>
> <read_diskdump: addr: ffffffff8bd25820 paddr: 9925820 cnt: 8>
> PAGESIZE=4096
> mem_section_size = 16384
> NR_SECTION_ROOTS = 2048
> NR_MEM_SECTIONS = 524288
> SECTIONS_PER_ROOT = 256
> SECTION_ROOT_MASK = 0xff
> PAGES_PER_SECTION = 32768
> <readmem: ffffffff8bd26db0, KVADDR, "mem_section", 8, (FOE), 7ffdbf96a440>
> <read_diskdump: addr: ffffffff8bd26db0 paddr: 9926db0 cnt: 8>
> <readmem: ffff8f4fff7fc000, KVADDR, "memory section root table", 16384, (FOE), 55e06391b840>
> <read_diskdump: addr: ffff8f4fff7fc000 paddr: 3f7fc000 cnt: 4096>
> crash: read error: kernel virtual address: ffff8f4fff7fc000 type: "memory section root table"
>
> The address (ffff8f4fff7fc000) seems to be inside the LOAD[4] range and is recorded as 'mem_section' with
> VMCOREINFO.
Yes, this says it's sane, and its paddr also looks sane..
So I'm not sure why read_diskdump() returns READ_ERROR, could you debug it?
I'm suspecting the read() below in cache_page() returns something, e.g.
--- a/diskdump.c
+++ b/diskdump.c
@@ -1189,10 +1189,13 @@ cache_page(physaddr_t paddr)
return PAGE_INCOMPLETE;
}
} else {
+ ssize_t r;
if (lseek(dd->dfd, pd.offset, SEEK_SET) == failed)
return SEEK_ERROR;
- if (read(dd->dfd, dd->compressed_page, pd.size) != pd.size)
+ if ((r = read(dd->dfd, dd->compressed_page, pd.size)) != pd.size) {
+ error(INFO, "errno=%d r=%ld pd.size=%u\n", errno, r, pd.size);
return READ_ERROR;
+ }
}
if (pd.flags & DUMP_DH_COMPRESSED_ZLIB) {
although another path may be returning it.
Thanks,
Kazu
1 year, 11 months
[PATCH V2 0/5] Fixups to work with crash tool
by Xianting Tian
I ever sent the patch 1 in the link:
https://patchwork.kernel.org/project/linux-riscv/patch/20220708073150.352...
And patch 2,3 in the link:
https://patchwork.kernel.org/project/linux-riscv/patch/20220714113300.367...
https://patchwork.kernel.org/project/linux-riscv/patch/20220714113300.367...
This patch series just put these patches together, and with two new patch 4, 5.
these five patches are the fixups for machine_kexec, kernel mode PC for vmcore
and improvements for vmcoreinfo and memory layout dump.
The main changes in the five patchs as below,
Patch 1: use __smp_processor_id() instead of smp_processor_id() to cleanup
the console prints.
Patch 2: Add VM layout, va bits, ram base to vmcoreinfo, which can simplify
the development of crash tool as ARM64 already did
(arch/arm64/kernel/crash_core.c).
Patch 3: Add modules to virtual kernel memory layout dump.
Patch 4: Fixup to get correct kernel mode PC for vmcore.
Patch 5: Updates vmcoreinfo.rst.
With these 5 patches(patch 2 is must), crash tool can work well to analyze
a vmcore. The patches for crash tool for RISCV64 is in the link:
https://lore.kernel.org/linux-riscv/20220718025346.411758-1-xianting.tian...
Changes v1 -> v2:
1, remove the patch "Add a fast call path of crash_kexec()" from this series
of patches, as it already applied to riscv git.
https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/commit/?h...
2, add 'Reviewed-by' based on the comments of v1.
Xianting Tian (5):
RISC-V: use __smp_processor_id() instead of smp_processor_id()
RISC-V: Add arch_crash_save_vmcoreinfo support
riscv: Add modules to virtual kernel memory layout dump
RISC-V: Fixup getting correct current pc
riscv64: crash_core: Export kernel vm layout, phys_ram_base
.../admin-guide/kdump/vmcoreinfo.rst | 31 +++++++++++++++++++
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/crash_core.c | 29 +++++++++++++++++
arch/riscv/kernel/crash_save_regs.S | 2 +-
arch/riscv/kernel/machine_kexec.c | 2 +-
arch/riscv/mm/init.c | 4 +++
6 files changed, 67 insertions(+), 2 deletions(-)
create mode 100644 arch/riscv/kernel/crash_core.c
--
2.17.1
1 year, 11 months
[PATCH 0/5] Fixups to work with crash tool
by Xianting Tian
I ever sent the patch 1,2 in the link:
https://patchwork.kernel.org/project/linux-riscv/patch/20220708073150.352...
https://patchwork.kernel.org/project/linux-riscv/patch/20220708073150.352...
And patch 3,4 in the link:
https://patchwork.kernel.org/project/linux-riscv/patch/20220714113300.367...
https://patchwork.kernel.org/project/linux-riscv/patch/20220714113300.367...
This patch series just put these patches together, and with a new patch 5.
these five patches are the fixups for kexec, vmcore and improvements
for vmcoreinfo and memory layout dump.
The main changes in the five patchs as below,
Patch 1: Add a fast call path of crash_kexec() as other Arch(x86, arm64) do.
Patch 2: use __smp_processor_id() instead of smp_processor_id() to cleanup
the console prints.
Patch 3: Add VM layout, va bits, ram base to vmcoreinfo, which can simplify
the development of crash tool as ARM64 already did
(arch/arm64/kernel/crash_core.c).
Patch 4: Add modules to virtual kernel memory layout dump.
Patch 5: Fixup to get correct kernel mode PC for vmcore
With these 5 patches(patch 3 is must), crash tool can work well to analyze
a vmcore. The patches for crash tool for RISCV64 is in the link:
https://lore.kernel.org/linux-riscv/20220717042929.370022-1-xianting.tian...
Xianting Tian (5):
RISC-V: Fixup fast call of crash_kexec()
RISC-V: use __smp_processor_id() instead of smp_processor_id()
RISC-V: Add arch_crash_save_vmcoreinfo support
riscv: Add modules to virtual kernel memory layout dump
RISC-V: Fixup getting correct current pc
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/crash_core.c | 29 +++++++++++++++++++++++++++++
arch/riscv/kernel/crash_save_regs.S | 2 +-
arch/riscv/kernel/machine_kexec.c | 2 +-
arch/riscv/kernel/traps.c | 4 ++++
arch/riscv/mm/init.c | 4 ++++
6 files changed, 40 insertions(+), 2 deletions(-)
create mode 100644 arch/riscv/kernel/crash_core.c
--
2.17.1
1 year, 11 months
[PATCH 0/8] Support RISCV64 arch and common commands
by Xianting Tian
This series of patches make crash tool support RISCV64 arch and the common
commands(*, bt, p, rd, mod, log, set, struct, task, dis and so on).
To make the crash tool work normally for RISCV64 arch, we need a Linux kernel
patch(under reviewing), which exports the kernel virtual memory layout, va_bits,
phys_ram_base to vmcoreinfo, it can simplify the development of crash tool.
THis Linux kernel patch:
https://patchwork.kernel.org/project/linux-riscv/patch/20220714113300.367...
This series of patches are tested on QEMU RISCV64 env and SoC platform of
T-head Xuantie 910 CPU.
====================================
Some test examples list as below
====================================
... ...
KERNEL: vmlinux
DUMPFILE: vmcore
CPUS: 1
DATE: Fri Jul 15 10:24:25 CST 2022
UPTIME: 00:00:33
LOAD AVERAGE: 0.05, 0.01, 0.00
TASKS: 41
NODENAME: buildroot
RELEASE: 5.18.9
VERSION: #30 SMP Fri Jul 15 09:47:03 CST 2022
MACHINE: riscv64 (unknown Mhz)
MEMORY: 1 GB
PANIC: "Kernel panic - not syncing: sysrq triggered crash"
PID: 113
COMMAND: "sh"
TASK: ff60000002269600 [THREAD_INFO: ff60000002269600]
CPU: 0
STATE: TASK_RUNNING (PANIC)
carsh>
crash> p mem_map
mem_map = $1 = (struct page *) 0xff6000003effbf00
crash> p /x *(struct page *) 0xff6000003effbf00
$5 = {
flags = 0x1000,
{
{
{
lru = {
next = 0xff6000003effbf08,
prev = 0xff6000003effbf08
},
{
__filler = 0xff6000003effbf08,
mlock_count = 0x3effbf08
}
},
mapping = 0x0,
index = 0x0,
private = 0x0
},
... ...
crash> mod
MODULE NAME BASE SIZE OBJECT FILE
ffffffff0113e740 nvme_core ffffffff01133000 98304 (not loaded) [CONFIG_KALLSYMS]
ffffffff011542c0 nvme ffffffff0114c000 61440 (not loaded) [CONFIG_KALLSYMS]
crash> rd ffffffff0113e740 8
ffffffff0113e740: 0000000000000000 ffffffff810874f8 .........t......
ffffffff0113e750: ffffffff011542c8 726f635f656d766e .B......nvme_cor
ffffffff0113e760: 0000000000000065 0000000000000000 e...............
ffffffff0113e770: 0000000000000000 0000000000000000 ................
crash> vtop ffffffff0113e740
VIRTUAL PHYSICAL
ffffffff0113e740 8254d740
PGD: ffffffff810e9ff8 => 2ffff001
P4D: 0000000000000000 => 000000002fffec01
PUD: 00005605c2957470 => 0000000020949801
PMD: 00007fff7f1750c0 => 0000000020947401
PTE: 0 => 209534e7
PAGE: 000000008254d000
PTE PHYSICAL FLAGS
209534e7 8254d000 (PRESENT|READ|WRITE|GLOBAL|ACCESSED|DIRTY)
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ff6000003f0777d8 8254d000 0 0 1 0
crash> bt
PID: 113 TASK: ff6000000226c200 CPU: 0 COMMAND: "sh"
#0 [ff20000010333b90] riscv_crash_save_regs at ffffffff800078f8
#1 [ff20000010333cf0] panic at ffffffff806578c6
#2 [ff20000010333d50] sysrq_reset_seq_param_set at ffffffff8038c03c
#3 [ff20000010333da0] __handle_sysrq at ffffffff8038c604
#4 [ff20000010333e00] write_sysrq_trigger at ffffffff8038cae4
#5 [ff20000010333e20] proc_reg_write at ffffffff801b7ee8
#6 [ff20000010333e40] vfs_write at ffffffff80152bb2
#7 [ff20000010333e80] ksys_write at ffffffff80152eda
#8 [ff20000010333ed0] sys_write at ffffffff80152f52
Xianting Tian (8):
Add RISCV64 framework code support
RISCV64: Make crash tool enter command line and support some commands
RISCV64: Add 'dis' command support
RISCV64: Add 'irq' command support
RISCV64: Add 'bt' command support
RISCV64: Add 'help -r' command support
RISCV64: Add 'mach' command support
RISCV64: Add the implementation of symbol verify
Makefile | 7 +-
README | 2 +-
configure.c | 39 +-
defs.h | 248 +++++++-
diskdump.c | 21 +-
help.c | 2 +-
lkcd_vmdump_v2_v3.h | 2 +-
netdump.c | 22 +-
ramdump.c | 2 +
riscv64.c | 1414 +++++++++++++++++++++++++++++++++++++++++++
symbols.c | 10 +
11 files changed, 1759 insertions(+), 10 deletions(-)
create mode 100644 riscv64.c
--
2.17.1
1 year, 11 months
Re: [Crash-utility] [PATCH v2 4/4] make: replace make by $(MAKE)
by lijiang
Hi, Sven and Kazu
The patchset really saves compilation time for crash build and the
following three patches look good to me(need a minor adjustment as Kazu
mentioned).
Thank you for the work, Sven.
[PATCH v2 1/4] make: set --no-print-directory once
[PATCH v2 3/4] make: use -C instead of (cd x; make)
[PATCH v2 4/4] make: replace make by $(MAKE)
Given that the gdb patch has specific rules, Kazu(or me) can help to pack
them into one patch with Sven's signature, if you have no objections.
Or could you please update the patchset? Sven.
Thanks.
Lianbo
On Thu, Dec 23, 2021 at 5:14 PM <crash-utility-request(a)redhat.com> wrote:
> Date: Thu, 23 Dec 2021 00:33:16 +0000
> From: HAGIO KAZUHITO(?????) <k-hagio-ab(a)nec.com>
> To: Sven Schnelle <svens(a)linux.ibm.com>
> Cc: "Discussion list for crash utility usage, maintenance and
> development" <crash-utility(a)redhat.com>
> Subject: Re: [Crash-utility] [PATCH v2 4/4] make: replace make by
> $(MAKE)
> Message-ID:
> <
> OS3PR01MB677601D042591DF6451F477DDD7E9(a)OS3PR01MB6776.jpnprd01.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="iso-2022-jp"
>
> Hi Sven,
>
> thank you for the update.
>
> -----Original Message-----
> > diff --git a/gdb-10.2.patch b/gdb-10.2.patch
> > index 1280d0688e83..afdbe99eae0d 100644
> > --- a/gdb-10.2.patch
> > +++ b/gdb-10.2.patch
> > @@ -73,7 +73,7 @@
> > # Removing the old gdb first works better if it is running, at least
> on SunOS.
> > gdb$(EXEEXT): gdb.o $(LIBGDB_OBS) $(CDEPS) $(TDEPLIBS)
> > $(SILENCE) rm -f gdb$(EXEEXT)
> > -+ @make -C ../.. GDB_FLAGS=-DGDB_10_2 library
> > ++ @$(MAKE) -C ../.. GDB_FLAGS=-DGDB_10_2 library
> > $(ECHO_CXXLD) $(CC_LD) $(INTERNAL_LDFLAGS) $(WIN32LDAPP) \
> > - -o gdb$(EXEEXT) gdb.o $(LIBGDB_OBS) \
> > - $(TDEPLIBS) $(TUI_LIBRARY) $(CLIBS) $(LOADLIBES)
>
> When detecting any change of the gdb patch, it tries to re-apply the new
> one
> using "patch -N --fuzz=0" in order to update the gdb. Please refer to
> Makefile::rebuild and the head of the gdb-10.2.patch.
>
> So I think that, to make a change to the gdb sources,
>
> 1. we have to "add" patches to the end of the gdb patch, and
> 2. if there are multiple patches for a gdb file, the "patch -N" doesn't
> work,
> so we have to revert the gdb file to the original one.
>
> (I will add this custom to crash guidelines later..)
>
> In your patches, there are multiple patches for gdb-10.2/gdb/Makefile.in
> so I would suggest that:
>
> 1. pack the 1/4, 3/4 and 4/4 patches into a patch, do the three things
> together.
> 2. add a hunk for the gdb-10.2/gdb/Makefile.in to the end of the
> gdb-10.2.patch.
> 3. add the following change to the head the gdb-10.2.patch.
>
> --- a/gdb-10.2.patch
> +++ b/gdb-10.2.patch
> @@ -8,6 +8,11 @@
> # shell script that can restore any gdb file to its original state prior
> # to all subsequent patch applications.
>
> +tar xvzmf gdb-10.2.tar.gz \
> + gdb-10.2/gdb/Makefile.in
> +
> +exit 0
> +
>
> (yeah, we forgot the "exit 0" here when moving to gdb-10.2..)
>
> Thanks,
> Kazu
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 23 Dec 2021 14:42:33 +0800
> From: Lianbo Jiang <lijiang(a)redhat.com>
> To: crash-utility(a)redhat.com
> Subject: [Crash-utility] [PATCH] Handle blk_mq_ctx member changes for
> kernels v5.16-rc1~75^2~44
> Message-ID: <20211223064233.16028-1-lijiang(a)redhat.com>
>
> Kernel commit <9a14d6ce4135> ("block: remove debugfs blk_mq_ctx
> dispatched/merged/completed attributes") removed the member
> rq_dispatched and rq_completed from struct blk_mq_ctx. Without
> this patch, crash will fail with the following error:
>
> crash> dev -d
> MAJOR GENDISK NAME REQUEST_QUEUE TOTAL ASYNC SYNC
>
> dev: invalid structure member offset: blk_mq_ctx_rq_dispatched
> FILE: dev.c LINE: 4229 FUNCTION: get_one_mctx_diskio()
>
> Signed-off-by: Lianbo Jiang <lijiang(a)redhat.com>
> ---
> dev.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/dev.c b/dev.c
> index effe789f38d8..dd21511e5dfc 100644
> --- a/dev.c
> +++ b/dev.c
> @@ -4246,6 +4246,10 @@ get_mq_diskio(unsigned long q, unsigned long
> *mq_count)
> unsigned long mctx_addr;
> struct diskio tmp;
>
> + if (!MEMBER_EXISTS("blk_mq_ctx", "rq_dispatched") &&
> + !MEMBER_EXISTS("blk_mq_ctx", "rq_completed"))
> + return;
> +
> memset(&tmp, 0x00, sizeof(struct diskio));
>
> readmem(q + OFFSET(request_queue_queue_ctx), KVADDR, &queue_ctx,
> --
> 2.20.1
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 23 Dec 2021 09:13:19 +0000
> From: "d.hatayama(a)fujitsu.com" <d.hatayama(a)fujitsu.com>
> To: "shogo.matsumoto(a)fujitsu.com" <shogo.matsumoto(a)fujitsu.com>
> Cc: "'crash-utility(a)redhat.com'" <crash-utility(a)redhat.com>
> Subject: Re: [Crash-utility] [PATCH] log: output logs of printk safe
> buffers
> Message-ID:
> <
> TYAPR01MB6507BFD2235A5C6806C3D0E5957E9(a)TYAPR01MB6507.jpnprd01.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="iso-2022-jp"
>
> Hi,
>
> >
> > ________________________________________
> > From: crash-utility-bounces(a)redhat.com <crash-utility-bounces(a)redhat.com>
> on behalf of shogo.matsumoto(a)fujitsu.com <shogo.matsumoto(a)fujitsu.com>
> > Sent: Thursday, December 16, 2021 16:39
> > To: 'crash-utility(a)redhat.com'
> > Subject: [Crash-utility] [PATCH] log: output logs of printk safe buffers
> >
> > We sometimes overlook logs written to printk safe buffers
> > (safe_print_seq/nmi_print_seq) which have not been flushed yet.
> >
> > This patch will output unflushed logs of the safe buffers
> > at the bottom of log command output as follows:
> >
> > [nmi_print_seq] CPU: 0 BUFFER: ffff888063c18ac0 LEN: 28
> > nmi print seq test message
> > [safe_print_seq] CPU: 1 BUFFER: ffff888063d19ae0 LEN: 30
> > safe print seq test message
>
> Could you share how to test this patch?
> such as how to create a memory dump where some messages are left
> in each log buffers without being flushed.
> I guess it would be helpful for reviewers.
>
> >
> > Note that the safe buffer (struct printk_safe_seq_buf) was introduced
> > in kernel-4.11 and removed in kernel-5.15.
>
> Describing the exact commit hashs in the kernel git repo are helpful.
>
> >
> > Signed-off-by: Shogo Matsumoto <shogo.matsumoto(a)fujitsu.com>
> > ---
> > defs.h | 3 +++
> > kernel.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 61 insertions(+)
> >
> > diff --git a/defs.h b/defs.h
> > index 7e2a16e..3ee51e0 100644
> > --- a/defs.h
> > +++ b/defs.h
> > @@ -2146,6 +2146,8 @@ struct offset_table { /* stash
> of commonly-used offsets */
> > long wait_queue_entry_private;
> > long wait_queue_head_head;
> > long wait_queue_entry_entry;
> > + long printk_safe_seq_buf_len;
> > + long printk_safe_seq_buf_buffer;
> > };
> >
> > struct size_table { /* stash of commonly-used sizes */
> > @@ -2310,6 +2312,7 @@ struct size_table { /* stash of
> commonly-used sizes */
> > long prb_desc;
> > long wait_queue_entry;
> > long task_struct_state;
> > + long printk_safe_seq_buf_buffer;
> > };
>
> Could you add support for the new members to help -o?
>
> help -o dumps contents of offset_table, size_table and array_table:
>
> crash> help help
>
> NAME
> help -get help
> ...snip...
> -n - dumpfile contents/statistics
> -o - offset_table and size_table
> -p - program_context
> -r - dump registers from dumpfile header
> -s - symbol table data
> -t - task_table
> -T - task_table plus context_array
> -v - vm_table
> -V - vm_table (verbose)
> -x - text cache
> -z - help options
> crash> help -o | tail
> prio_array_queue: 0
> height_to_maxindex: 0
> height_to_maxnodes: 0
> pid_hash: 0
> kmem_cache_node: 1024
> kmem_cache_cpu_slab: 0
> rt_prio_array_queue: 0
> task_struct_rlim: 0
> signal_struct_rlim: 0
> vm_numa_stat: 0
>
>
> >
> > struct array_table {
> > diff --git a/kernel.c b/kernel.c
> > index f4598ea..cc97176 100644
> > --- a/kernel.c
> > +++ b/kernel.c
> > @@ -93,6 +93,7 @@ static void source_tree_init(void);
> > static ulong dump_audit_skb_queue(ulong);
> > static ulong __dump_audit(char *);
> > static void dump_audit(void);
> > +static void dump_printk_safe_seq_buf(void);
> > static char *vmcoreinfo_read_string(const char *);
> > static void check_vmcoreinfo(void);
> > static int is_pvops_xen(void);
> > @@ -5048,6 +5049,7 @@ cmd_log(void)
> > }
> >
> > dump_log(msg_flags);
> > + dump_printk_safe_seq_buf();
> > }
> >
> >
> > @@ -11534,6 +11536,62 @@ dump_audit(void)
> > error(INFO, "kernel audit log is empty\n");
> > }
> >
> > +static void
> > +__dump_printk_safe_seq_buf(char *buf_name)
> > +{
> > + int cpu, buffer_size;
> > + char *buffer;
> > +
> > + if (!symbol_exists(buf_name)) {
> > + return;
> > + }
> > +
> > + buffer_size = SIZE(printk_safe_seq_buf_buffer);
> > + buffer = GETBUF(buffer_size);
> > + for (cpu = 0; cpu < kt->cpus; cpu++) {
> > + ulong len_addr, buffer_addr;
> > + int len;
> > +
> > + len_addr = symbol_value(buf_name) +
> kt->__per_cpu_offset[cpu] + OFFSET(printk_safe_seq_buf_len);
> > + buffer_addr = symbol_value(buf_name) +
> kt->__per_cpu_offset[cpu] + OFFSET(printk_safe_seq_buf_buffer);
> > + readmem(len_addr, KVADDR, &len, STRUCT_SIZE("atomic_t"),
> "printk_safe_seq_buf len", FAULT_ON_ERROR);
> > + readmem(buffer_addr, KVADDR, buffer, buffer_size,
> "printk_safe_seq_buf buffer", FAULT_ON_ERROR);
> > +
> > + if (len > 0) {
> > + int i, n;
> > + char *p;
> > + fprintf(fp, "[%s] CPU: %d BUFFER: %lx LEN:
> %d\n", buf_name, cpu, buffer_addr, len);
> > + n = (len <= buffer_size) ? len : buffer_size;
> > + for (i = 0, p = buffer; i < n; i++, p++) {
> > + if (*p == 0x1) { //SOH
> > + i++; p++;
> > + continue;
> > + } else {
> > + fputc(ascii(*p) ? *p : '.', fp);
> > + }
> > + }
> > + fputc('\n', fp);
> > + }
> > + }
> > + FREEBUF(buffer);
> > +}
> > +
> > +static void
> > +dump_printk_safe_seq_buf(void)
> > +{
> > + if (!STRUCT_EXISTS("printk_safe_seq_buf"))
> > + return;
> > +
> > + if (INVALID_SIZE(printk_safe_seq_buf_buffer)) {
> > + MEMBER_OFFSET_INIT(printk_safe_seq_buf_len,
> "printk_safe_seq_buf", "len");
> > + MEMBER_OFFSET_INIT(printk_safe_seq_buf_buffer,
> "printk_safe_seq_buf", "buffer");
> > + MEMBER_SIZE_INIT(printk_safe_seq_buf_buffer,
> "printk_safe_seq_buf", "buffer");
> > + }
> > +
> > + __dump_printk_safe_seq_buf("nmi_print_seq");
> > + __dump_printk_safe_seq_buf("safe_print_seq");
> > +}
> > +
> > /*
> > * Reads a string value from the VMCOREINFO data stored in (live)
> memory.
> > *
>
>
>
>
>
> ------------------------------
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://listman.redhat.com/mailman/listinfo/crash-utility
>
> End of Crash-utility Digest, Vol 195, Issue 24
> **********************************************
>
>
1 year, 11 months
[PATCH v2] arm64: Fix for st->_stext_vmlinux not initialized when set VA_BITS_ACTUAL
by Qianli Zhao
From: Qianli Zhao <qianli.zhao(a)horizon.ai>
Setting st->_stext_vmlinux to UNINITIALIZED to search for "_stext"
from the vmlinux. In the scenario where kaslr is disabled and
without vmcore file, will get the wrong MODULES/VMALLOC ranges,
cause parsing raw dumpfile failure
Signed-off-by: Qianli Zhao <qianli.zhao(a)horizon.ai>
---
v2: Update patch log and add some comment in code.
---
arm64.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arm64.c b/arm64.c
index 0f615cf..5d306cd 100644
--- a/arm64.c
+++ b/arm64.c
@@ -149,6 +149,15 @@ arm64_init(int when)
ms = machdep->machspec;
+ /*
+ * The st->_stext_vmlinux is needed in arm64_init(PRE_GDB) when a
+ * dumpfile does not have vmcoreinfo and we use -m vabits_actual
+ * option, e.g. a raw RAM dumpfile.
+ *
+ */
+ if (ms->VA_BITS_ACTUAL)
+ st->_stext_vmlinux = UNINITIALIZED;
+
if (!ms->kimage_voffset && STREQ(pc->live_memsrc, "/dev/crash"))
ioctl(pc->mfd, DEV_CRASH_ARCH_DATA, &ms->kimage_voffset);
--
2.17.1
1 year, 12 months
[PATCH v2 0/6] bt fixes and cleanup for ppc64
by Hari Bathini
This patch series fixes a couple of issues with bt on ppc64 and also
does some code cleanup.
Patch #1 fixes the broken '-S' option on ppc64. The next patch changes
h/w interrupt stack allocation to dynamic as this field remains unused
in most cases. The next patch renames ppc64_paca_init() function to
ppc64_paca_percpu_offset_init() to reflect what the function actually
does. Patch#4 adds support to process backtrace when the stack pointer
is in an emergency SP. The next patch adds support to print emergency
stack data. And the last patch ensures a variable is used instead of
machdep->machspec to optimize code and improve readability.
Changes in v2:
* Print "(unused)", if hwintrstack is not being used.
* Avoid using variable length array for paca_ptrs.
* With 'mach' command, print emergency stack data by default
(no special option).
Hari Bathini (6):
ppc64: fix bt for '-S' case
ppc64: dynamically allocate h/w interrupt stack
ppc64: rename ppc64_paca_init to ppc64_paca_percpu_offset_init
ppc64: handle backtrace when CPU is in an emerency stack
ppc64: print emergency stacks info with 'mach' command
ppc64: use a variable for machdep->machspec
defs.h | 14 +-
ppc64.c | 535 ++++++++++++++++++++++++++++++++++++++++----------------
2 files changed, 393 insertions(+), 156 deletions(-)
--
2.35.3
1 year, 12 months