April 2021 - Crash-utility - Crash Utility List Archives

[PATCH] Fix gcc_version character display

by Youling Tang

When using the "help -k" command in the 5.12 kernel, it was found that the gcc_version character string was displayed as 0.0.0. Check the value of the proc_version string to know, crash> help -k ... proc_version: Linux version 5.12.0-rc2kexec+ (root@bogon) (gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-6), GNU ld version 2.28-13.fc21.loongson.6) #30 SMP PREEMPT Thu Apr 22 09:04:57 HKT 2021 ... Therefore, the "gcc (GCC)" character should be searched to obtain the correct character string "gcc_version" value. Signed-off-by: Youling Tang <tangyouling(a)loongson.cn> --- kernel.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/kernel.c b/kernel.c index 528f6ee..a1872c2 100644 --- a/kernel.c +++ b/kernel.c @@ -1103,9 +1103,13 @@ verify_version(void) /* * Keeping the gcc version with #define's is getting out of hand. */ - if ((p1 = strstr(kt->proc_version, "gcc version "))) { + if ((p1 = strstr(kt->proc_version, "gcc version ")) || + (p1 = strstr(kt->proc_version, "gcc (GCC) "))) { BZERO(buf, BUFSIZE); - p1 += strlen("gcc version "); + if (strstr(kt->proc_version, "gcc version ")) + p1 += strlen("gcc version "); + else + p1 += strlen("gcc (GCC) "); p2 = buf; while (((*p1 >= '0') && (*p1 <= '9')) || (*p1 == '.')) { if (*p1 == '.') @@ -3661,7 +3665,7 @@ module_init(void) modules_found = TRUE; break; } - } + } if (!modules_found) { error(WARNING, -- 2.1.0

4 years

3
5
0 / 0

Re: [Crash-utility] [PATCH 1/1] tools: list: create O option for specifying head node offset

by Firo Yang

The 04/20/2021 13:44, Firo Yang wrote: Hi Kazu-san, > This new O option is very useful to specify the head node > offset for listing linked list whose head node embedded has a > different offset to other node, e.g. dentry.d_subdirs(the head node) > and dentry.d_child. > > Signed-off-by: Firo Yang <firo.yang(a)suse.com> > --- > defs.h | 1 + > help.c | 12 +++++++++++- > tools.c | 30 +++++++++++++++++++++++++++--- > 3 files changed, 39 insertions(+), 4 deletions(-) > > diff --git a/defs.h b/defs.h > index 35b983a..764facf 100644 > --- a/defs.h > +++ b/defs.h > @@ -2605,6 +2605,7 @@ struct list_data { /* generic structure used by do_list() to walk */ > #define LIST_PARSE_MEMBER (VERBOSE << 13) > #define LIST_READ_MEMBER (VERBOSE << 14) > #define LIST_BRENT_ALGO (VERBOSE << 15) > +#define LIST_HEAD_OFFSET_ENTERED (VERBOSE << 16) > > struct tree_data { > ulong flags; > diff --git a/help.c b/help.c > index 531f50a..b561f3b 100644 > --- a/help.c > +++ b/help.c > @@ -5716,7 +5716,7 @@ char *help__list[] = { > "list", > "linked list", > "[[-o] offset][-e end][-[s|S] struct[.member[,member] [-l offset]] -[x|d]]" > -"\n [-r|-B] [-h|-H] start", > +"\n [-r|-B] [-h [-O head_offset]|-H] start", > " ", > " This command dumps the contents of a linked list. The entries in a linked", > " list are typically data structures that are tied together in one of two", > @@ -5800,6 +5800,16 @@ char *help__list[] = { > " -S struct Similar to -s, but instead of parsing gdb output, member values", > " are read directly from memory, so the command works much faster", > " for 1-, 2-, 4-, and 8-byte members.", > +" -O offset The -O option works only with -h option.", > +" It is used for specifying the offset of head node embedded in a", > +" structure, like dentry.d_subdirs or cgroup_subsys_state.children.", > +" The offset may be entered in either of two manners:", > +"", > +" 1. \"structure.member\" format.", > +" 2. a number of bytes.", > +"", > +" You can use it like the following:", > +" list -O <head node offset> -o <node offset> -h start -s <...>", > " -l offset Only used in conjunction with -s, if the start address argument", > " is a pointer to an embedded list head (or any other similar list", > " linkage structure whose first member points to the next linkage", > diff --git a/tools.c b/tools.c > index a26b101..792a567 100644 > --- a/tools.c > +++ b/tools.c > @@ -3343,6 +3343,7 @@ void > cmd_list(void) > { > int c; > + long head_member_offset; /* offset for head like denty.d_subdirs */ > struct list_data list_data, *ld; > struct datatype_member struct_member, *sm; > struct syment *sp; > @@ -3353,7 +3354,7 @@ cmd_list(void) > BZERO(ld, sizeof(struct list_data)); > struct_list_offset = 0; > > - while ((c = getopt(argcnt, args, "BHhrs:S:e:o:xdl:")) != EOF) { > + while ((c = getopt(argcnt, args, "BHhrs:S:e:o:O:xdl:")) != EOF) { > switch(c) > { > case 'B': > @@ -3394,6 +3395,24 @@ cmd_list(void) > optarg); > break; > > + case 'O': > + if (ld->flags & LIST_HEAD_OFFSET_ENTERED) > + error(FATAL, > + "offset value %d (0x%lx) already entered\n", > + head_member_offset, head_member_offset); > + else if (IS_A_NUMBER(optarg)) > + head_member_offset = stol(optarg, > + FAULT_ON_ERROR, NULL); > + else if (arg_to_datatype(optarg, > + sm, RETURN_ON_ERROR) > 1) > + head_member_offset = sm->member_offset; > + else > + error(FATAL, "invalid -O argument: %s\n", > + optarg); > + > + ld->flags |= LIST_HEAD_OFFSET_ENTERED; > + break; > + > case 'o': > if (ld->flags & LIST_OFFSET_ENTERED) > error(FATAL, > @@ -3599,8 +3618,13 @@ next_arg: > fprintf(fp, "(empty)\n"); > return; > } > - } else > - ld->start += ld->list_head_offset; > + } else { > + if (ld->flags & LIST_HEAD_OFFSET_ENTERED) > + readmem(ld->start + head_member_offset, KVADDR, > + &ld->start, sizeof(void *), "LIST_HEAD contents", FAULT_ON_ERROR); > + else > + ld->start += ld->list_head_offset; > + } > } > > ld->flags &= ~(LIST_OFFSET_ENTERED|LIST_START_ENTERED); > -- > 2.30.2 > I am not sure whether this patch is considered helpful or not. Could you please share some thoughts? Thanks, Firo

4 years

1
0
0 / 0

[PATCH] Add alternate HZ calculation using write_expire

by HAGIO KAZUHITO(萩尾　一仁)

Linux 4.8 and later kernels that contain kernel commit 9a7f38c42c2b ("cfq-iosched: Convert from jiffies to nanoseconds") changed the definition of cfq_slice_async, and it cannot be used to calculate the HZ value. Add alternate HZ calculation using write_expire, which depends on CONFIG_MQ_IOSCHED_DEADLINE or CONFIG_IOSCHED_DEADLINE. Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com> --- task.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/task.c b/task.c index ce2b55f430e0..36cf259e5d7b 100644 --- a/task.c +++ b/task.c @@ -432,6 +432,29 @@ task_init(void) "cfq_slice_async exists: setting hz to %d\n", machdep->hz); } + } else if ((symbol_exists("dd_init_queue") && + gdb_set_crash_scope(symbol_value("dd_init_queue"), "dd_init_queue")) || + (symbol_exists("deadline_init_queue") && + gdb_set_crash_scope(symbol_value("deadline_init_queue"), "deadline_init_queue"))) { + char buf[BUFSIZE]; + uint write_expire = 0; + + open_tmpfile(); + sprintf(buf, "printf \"%%d\", write_expire"); + if (gdb_pass_through(buf, pc->tmpfile, GNU_RETURN_ON_ERROR)) { + rewind(pc->tmpfile); + if (fgets(buf, BUFSIZE, pc->tmpfile)) + sscanf(buf, "%d", &write_expire); + } + close_tmpfile(); + + if (write_expire) { + machdep->hz = write_expire / 5; + if (CRASHDEBUG(2)) + fprintf(fp, "write_expire exists: setting hz to %d\n", + machdep->hz); + } + gdb_set_crash_scope(0, NULL); } if (VALID_MEMBER(runqueue_arrays)) -- 2.18.4

4 years

2
2
0 / 0

Re: [Crash-utility] [PATCH] Skip alternate hz calculation in Linux 4.8+

by lijiang

在 2021年04月23日 00:00, crash-utility-request(a)redhat.com 写道: > Date: Thu, 22 Apr 2021 12:06:29 +0000 > From: "Moore, Martin (Linux ERT)" <martin.moore(a)hpe.com> > To: "Discussion list for crash utility usage, maintenance and > development" <crash-utility(a)redhat.com> > Subject: Re: [Crash-utility] [PATCH] Skip alternate hz calculation in > Linux 4.8+ > Message-ID: > <AT5PR8401MB1300438F403F7A3A9B6A12DC91469(a)AT5PR8401MB1300.NAMPRD84.PROD.OUTLOOK.COM> > > Content-Type: text/plain; charset="us-ascii" > > Hi Kazu, > >> Thank you for the report and patch, there is another discussion about the HZ calculation [1], but anyway I think we should have this patch. >> Acked-by: Kazuhito Hagio <k-hagio-ab(a)nec.com> >> Could I have your Signed-off-by: tag? > Yes, included below. Thanks. > > --- task.c.orig 2021-04-14 16:07:52.021137849 -0400 > +++ task.c 2021-04-14 16:11:03.406626370 -0400 > @@ -417,7 +417,8 @@ > > STRUCT_SIZE_INIT(cputime_t, "cputime_t"); > > - if (symbol_exists("cfq_slice_async")) { > + if ((THIS_KERNEL_VERSION < LINUX(4,8,0)) && > + symbol_exists("cfq_slice_async")) { > uint cfq_slice_async; > > get_symbol_data("cfq_slice_async", sizeof(int), > > Signed-off-by: Martin Moore <martin.moore(a)hpe.com> Acked-by: Lianbo Jiang <lijiang(a)redhat.com>

4 years

2
1
0 / 0

[PATCH] Fix machdep->HZ calculation for kernel versions > 2.6.0

by Bhupesh Sharma

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. I tested this on ppc64le and x86_64 and the hz value reported is 1000, whereas the kernel CONFIG_HZ_100 is set to Y. See some logs below: crash> help -m flags: 124000f5 (KSYMS_START|MACHDEP_BT_TEXT|VM_4_LEVEL|VMEMMAP|VMEMMAP_AWARE|PHYS_ENTRY_L4|SWAP_ENTRY_L4|RADIX_MMU|OPAL_FW) kvbase: c000000000000000 identity_map_base: c000000000000000 pagesize: 65536 pageshift: 16 pagemask: ffffffffffff0000 pageoffset: ffff stacksize: 16384 hz: 1000 mhz: 2800 [host@rhel7]$ grep CONFIG_HZ_100= redhat/configs/kernel-3.10.0-ppc64le.config CONFIG_HZ_100=y Fix the same by using the sysconf(_SC_CLK_TCK) value instead of the hardcoded HZ values depending on kernel versions. Cc: k-hagio-ab(a)nec.com Cc: lijiang(a)redhat.com Cc: bhupesh.linux(a)gmail.com Signed-off-by: Bhupesh Sharma <bhsharma(a)redhat.com> --- arm.c | 2 +- arm64.c | 2 +- ppc.c | 5 +---- ppc64.c | 6 ++---- x86.c | 5 +---- x86_64.c | 5 +---- 6 files changed, 7 insertions(+), 18 deletions(-) diff --git a/arm.c b/arm.c index e52d29f04015..234feca7d1df 100644 --- a/arm.c +++ b/arm.c @@ -326,7 +326,7 @@ arm_init(int when) "pr_reg"); if (!machdep->hz) - machdep->hz = 100; + machdep->hz = HZ; break; case POST_VM: diff --git a/arm64.c b/arm64.c index 37aed07edf1d..8226a8ed7929 100644 --- a/arm64.c +++ b/arm64.c @@ -457,7 +457,7 @@ arm64_init(int when) &machdep->nr_irqs); if (!machdep->hz) - machdep->hz = 100; + machdep->hz = HZ; arm64_irq_stack_init(); arm64_stackframe_init(); diff --git a/ppc.c b/ppc.c index cf5bf5688227..1c1c15a1fab3 100644 --- a/ppc.c +++ b/ppc.c @@ -401,11 +401,8 @@ ppc_init(int when) &machdep->nr_irqs); else machdep->nr_irqs = 512; /* NR_IRQS (at least) */ - if (!machdep->hz) { + if (!machdep->hz) machdep->hz = HZ; - if (THIS_KERNEL_VERSION >= LINUX(2,6,0)) - machdep->hz = 1000; - } if (symbol_exists("cur_cpu_spec")) { get_symbol_data("cur_cpu_spec", sizeof(void *), &cur_cpu_spec); readmem(cur_cpu_spec + MEMBER_OFFSET("cpu_spec", "cpu_user_features"), diff --git a/ppc64.c b/ppc64.c index f368bf8e1a08..0cc82ffbba0e 100644 --- a/ppc64.c +++ b/ppc64.c @@ -694,11 +694,9 @@ ppc64_init(int when) */ BZERO(&machdep->machspec->hwintrstack, NR_CPUS*sizeof(ulong)); - if (!machdep->hz) { + if (!machdep->hz) machdep->hz = HZ; - if (THIS_KERNEL_VERSION >= LINUX(2,6,0)) - machdep->hz = 1000; - } + /* * IRQ stacks are introduced in 2.6 and also configurable. */ diff --git a/x86.c b/x86.c index de0d3d3114d0..ab34052da7af 100644 --- a/x86.c +++ b/x86.c @@ -1998,11 +1998,8 @@ x86_init(int when) &machdep->nr_irqs); else machdep->nr_irqs = 224; /* NR_IRQS */ - if (!machdep->hz) { + if (!machdep->hz) machdep->hz = HZ; - if (THIS_KERNEL_VERSION >= LINUX(2,6,0)) - machdep->hz = 1000; - } if (machdep->flags & PAE) { if (THIS_KERNEL_VERSION < LINUX(2,6,26)) diff --git a/x86_64.c b/x86_64.c index 23a40a04bbc4..3e6750708659 100644 --- a/x86_64.c +++ b/x86_64.c @@ -660,11 +660,8 @@ x86_64_init(int when) machdep->show_interrupts = x86_64_show_interrupts; if (THIS_KERNEL_VERSION < LINUX(2,6,24)) machdep->line_number_hooks = x86_64_line_number_hooks; - if (!machdep->hz) { + if (!machdep->hz) machdep->hz = HZ; - if (THIS_KERNEL_VERSION >= LINUX(2,6,0)) - machdep->hz = 1000; - } machdep->section_size_bits = _SECTION_SIZE_BITS; if (!machdep->max_physmem_bits) { if ((string = pc->read_vmcoreinfo("NUMBER(MAX_PHYSMEM_BITS)"))) { -- 2.26.2

4 years

3
12
0 / 0

Re: [Crash-utility] [PATCH v2 00/17] Add MIPS64 support

by lijiang

Hi, Youling Thank you for the update. 在 2021年03月16日 17:39, crash-utility-request(a)redhat.com 写道: > Date: Tue, 16 Mar 2021 17:38:35 +0800 > From: Youling Tang <tangyouling(a)loongson.cn> > To: Kazuhito Hagio <k-hagio-ab(a)nec.com>, crash-utility(a)redhat.com > Cc: tangyouling(a)loongson.cn, Huacai Chen <chenhuacai(a)loongson.cn> > Subject: [Crash-utility] [PATCH v2 00/17] Add MIPS64 support > Message-ID: > <1615887532-23722-1-git-send-email-tangyouling(a)loongson.cn> > Content-Type: text/plain; charset=UTF-8 > > Initial support is limited to the 64-bit MIPS kernel, configured as little > endian. Regarding dump file types, vmcore and makedumpfile tools can be > used to dump compressed dumpfile files. Does not supports running a live > kernel. > There seem to be some limitations and unimplemented features. Do you have any plans to complete the remaining work? If I was wrong, please correct me. BTW: I have no MIPS machines, more things need to rely on MIPS engineers. Can other MIPS engineers help to test this patch? Thanks. Lianbo > The changes were tested on a mips64 Loongson-3A4000 processor. Can > successfully enter the crash command line and support for common > commands, such as bt, vtop, log commands, etc. > > Youling Tang (17): > Add MIPS64 framework code support > MIPS64: Support getting regs from kdump dumpfiles > MIPS64: Add gdb patch for Loongson machine > MIPS64: Make the crash tool successfully enter the crash command line > MIPS64: Add 'pte' command support > MIPS64: Add 'dis' command support > MIPS64: Fix display memory size issue > MIPS64: Add to get processor speed > MIPS64: Add 'mach' command support > MIPS64: Add basic support for the 'bt' command > MIPS64: Fixes for the gathering of the active task registers for the > 'bt' command > MIPS64: Add 'bt -f' command support > MIPS64: Add 'bt -l' command support > MIPS64: Add the realization of verify symbol > MIPS64: Add 'help -m/M' command support > MIPS64: Add 'help -r' command support > MIPS64: Add mips64 architecture support information > > Makefile | 7 +- > README | 4 +- > configure.c | 33 +- > defs.h | 139 +++++- > diskdump.c | 26 +- > gdb-7.6.patch | 21 +- > help.c | 4 +- > lkcd_vmdump_v2_v3.h | 3 +- > memory.c | 32 +- > mips64.c | 1365 +++++++++++++++++++++++++++++++++++++++++++++++++++ > netdump.c | 6 +- > symbols.c | 10 + > 12 files changed, 1621 insertions(+), 29 deletions(-) > create mode 100644 mips64.c > > -- 2.1.0

4 years

3
4
0 / 0

[PATCH] Skip alternate hz calculation in Linux 4.8+

by Moore, Martin (Linux ERT)

In task_init() there is a calculation of machdep->hz based on the value of cfq_slice_async if the symbol exists: if (symbol_exists("cfq_slice_async")) { uint cfq_slice_async; get_symbol_data("cfq_slice_async", sizeof(int), &cfq_slice_async); if (cfq_slice_async) { machdep->hz = cfq_slice_async * 25; if (CRASHDEBUG(2)) fprintf(fp, "cfq_slice_async exists: setting hz to %d\n", machdep->hz); } } However, patch "cfq-iosched: Convert from jiffies to nanoseconds" (https://patchwork.kernel.org/project/linux-block/patch/1465391499-27867-2...) changed the definition of cfq_slice_async from (HZ / 25) to (NSEC_PER_SEC / 25). As such, the above calculation will result in a value of 1000000000 for machdep->hz. In vmcores where the symbol exists and has this definition, this causes incorrect results for some calculations. I have a couple of 4.12 vmcores in this situation, and in them crash shows the uptime as 3 seconds, which also throws off the timestamps in "log -T". Fix this by skipping the above code block for kernels 4.8 and above: --- task.c.orig 2021-04-14 16:07:52.021137849 -0400 +++ task.c 2021-04-14 16:11:03.406626370 -0400 @@ -417,7 +417,8 @@ STRUCT_SIZE_INIT(cputime_t, "cputime_t"); - if (symbol_exists("cfq_slice_async")) { + if ((THIS_KERNEL_VERSION < LINUX(4,8,0)) && + symbol_exists("cfq_slice_async")) { uint cfq_slice_async; get_symbol_data("cfq_slice_async", sizeof(int), Martin Moore Linux Engineering Resolution Team HPE Pointnext Services Hewlett Packard Enterprise

4 years

2
2
0 / 0

[PATCH v2 00/17] Add MIPS64 support

by Youling Tang

Initial support is limited to the 64-bit MIPS kernel, configured as little endian. Regarding dump file types, vmcore and makedumpfile tools can be used to dump compressed dumpfile files. Does not supports running a live kernel. The changes were tested on a mips64 Loongson-3A4000 processor. Can successfully enter the crash command line and support for common commands, such as bt, vtop, log commands, etc. Youling Tang (17): Add MIPS64 framework code support MIPS64: Support getting regs from kdump dumpfiles MIPS64: Add gdb patch for Loongson machine MIPS64: Make the crash tool successfully enter the crash command line MIPS64: Add 'pte' command support MIPS64: Add 'dis' command support MIPS64: Fix display memory size issue MIPS64: Add to get processor speed MIPS64: Add 'mach' command support MIPS64: Add basic support for the 'bt' command MIPS64: Fixes for the gathering of the active task registers for the 'bt' command MIPS64: Add 'bt -f' command support MIPS64: Add 'bt -l' command support MIPS64: Add the realization of verify symbol MIPS64: Add 'help -m/M' command support MIPS64: Add 'help -r' command support MIPS64: Add mips64 architecture support information Makefile | 7 +- README | 4 +- configure.c | 33 +- defs.h | 139 +++++- diskdump.c | 26 +- gdb-7.6.patch | 21 +- help.c | 4 +- lkcd_vmdump_v2_v3.h | 3 +- memory.c | 32 +- mips64.c | 1365 +++++++++++++++++++++++++++++++++++++++++++++++++++ netdump.c | 6 +- symbols.c | 10 + 12 files changed, 1621 insertions(+), 29 deletions(-) create mode 100644 mips64.c -- 2.1.0

4 years

2
23
0 / 0

[PATCHv3] crash-utility/arm64: store phy_offset and memstart_addr separately

by Pingfan Liu

Crash encounters a bug like the following: ... License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "aarch64-unknown-linux-gnu"... crash: read error: kernel virtual address: ffff000f789c0050 type: "IRQ stack pointer" crash: read error: kernel virtual address: ffff000f78a60050 type: "IRQ stack pointer" crash: read error: kernel virtual address: ffff000f78b00050 type: "IRQ stack pointer" ... This bug connects with kernel commit 7bc1a0f9e176 ("arm64: mm: use single quantity to represent the PA to VA translation"), memstart_addr can be negative, which makes it different from real phys_offset. In crash utility, PTOV() needs memstart_addr to calculate VA from PA, while getting PFN offset in a dumpfile, phys_offset is required. To serve the different purpose, using phys_offset_nominal and phys_offset to store them. Signed-off-by: Pingfan Liu <piliu(a)redhat.com> Cc: HAGIO KAZUHITO <k-hagio-ab(a)nec.com> Cc: Lianbo Jiang <lijiang(a)redhat.com> Cc: Bhupesh Sharma <bhupesh.sharma(a)linaro.org> Cc: Mark Salter <msalter(a)redhat.com> Cc: Mark Langsdorf <mlangsdo(a)redhat.com> Cc: Jeremy Linton <jlinton(a)redhat.com> To: crash-utility(a)redhat.com --- v2 -> v3: rename ms->memstart_addr as ms->phys_offset_nominal ( I keep the name as phys_offset* since it is in accordance with other platform conventions) --- arm64.c | 25 ++++++++++++++++++++++--- defs.h | 3 +++ 2 files changed, 25 insertions(+), 3 deletions(-) diff --git a/arm64.c b/arm64.c index 37aed07..5e567ca 100644 --- a/arm64.c +++ b/arm64.c @@ -24,6 +24,9 @@ #define NOT_IMPLEMENTED(X) error((X), "%s: function not implemented\n", __func__) +#define MEMSTART_ADDR_OFFSET \ + (0xffffffffffffffff << 48 - 0xffffffffffffffff << 56) + static struct machine_specific arm64_machine_specific = { 0 }; static int arm64_verify_symbol(const char *, ulong, char); static void arm64_parse_cmdline_args(void); @@ -687,6 +690,7 @@ arm64_dump_machdep_table(ulong arg) fprintf(fp, " kimage_voffset: %016lx\n", ms->kimage_voffset); } fprintf(fp, " phys_offset: %lx\n", ms->phys_offset); + fprintf(fp, " phys_offset_nominal: %lx\n", ms->phys_offset_nominal); fprintf(fp, "__exception_text_start: %lx\n", ms->__exception_text_start); fprintf(fp, " __exception_text_end: %lx\n", ms->__exception_text_end); fprintf(fp, " __irqentry_text_start: %lx\n", ms->__irqentry_text_start); @@ -987,7 +991,7 @@ arm64_calc_physvirt_offset(void) ulong physvirt_offset; struct syment *sp; - ms->physvirt_offset = ms->phys_offset - ms->page_offset; + ms->physvirt_offset = ms->phys_offset_nominal - ms->page_offset; if ((sp = kernel_symbol_search("physvirt_offset")) && machdep->machspec->kimage_voffset) { @@ -1028,7 +1032,11 @@ arm64_calc_phys_offset(void) ms->kimage_voffset && (sp = kernel_symbol_search("memstart_addr"))) { if (pc->flags & PROC_KCORE) { if ((string = pc->read_vmcoreinfo("NUMBER(PHYS_OFFSET)"))) { - ms->phys_offset = htol(string, QUIET, NULL); + ms->phys_offset_nominal = htol(string, QUIET, NULL); + if (ms->phys_offset_nominal < 0) + ms->phys_offset = ms->phys_offset_nominal + MEMSTART_ADDR_OFFSET; + else + ms->phys_offset = ms->phys_offset_nominal; free(string); return; } @@ -1080,7 +1088,18 @@ arm64_calc_phys_offset(void) } else if (DISKDUMP_DUMPFILE() && diskdump_phys_base(&phys_offset)) { ms->phys_offset = phys_offset; } else if (KDUMP_DUMPFILE() && arm64_kdump_phys_base(&phys_offset)) { - ms->phys_offset = phys_offset; + /* + * When running a 52bits kernel on 48bits hardware. Kernel plays a trick: + * if (IS_ENABLED(CONFIG_ARM64_VA_BITS_52) && (vabits_actual != 52)) + * memstart_addr -= _PAGE_OFFSET(48) - _PAGE_OFFSET(52); + * + * In crash, this should be detected to get a real physical start address. + */ + ms->phys_offset_nominal = phys_offset; + if ((long)phys_offset < 0) + ms->phys_offset = phys_offset + MEMSTART_ADDR_OFFSET; + else + ms->phys_offset = phys_offset; } else { error(WARNING, "phys_offset cannot be determined from the dumpfile.\n"); diff --git a/defs.h b/defs.h index 35b983a..09d58e0 100644 --- a/defs.h +++ b/defs.h @@ -3289,7 +3289,10 @@ struct machine_specific { ulong vmemmap_end; ulong modules_vaddr; ulong modules_end; + /* real physical offset */ ulong phys_offset; + /* read from kernel symbol memstart_addr */ + long phys_offset_nominal; ulong __exception_text_start; ulong __exception_text_end; struct arm64_pt_regs *panic_task_regs; -- 2.29.2

4 years

3
2
0 / 0

Re: [Crash-utility] [PATCH] arm64: handle 1GB block

by lijiang

Hi, Johan Thanks for the fix. 在 2021年03月12日 01:00, crash-utility-request(a)redhat.com 写道: > Date: Thu, 11 Mar 2021 08:54:30 +0000 > From: <Johan.Erlandsson(a)sony.com> > To: <crash-utility(a)redhat.com> > Subject: [Crash-utility] [PATCH] arm64: handle 1GB block > Message-ID: > <AM0P193MB06428B158EE504FE3466B105E3909(a)AM0P193MB0642.EURP193.PROD.OUTLOOK.COM> > > Content-Type: text/plain; charset="us-ascii" > > With enough continuous physical memory we can have 1GB block. This have > been seen only in linear mapping region in kernel space. I have only > verified this for VM_L3_4K. > > reference: alloc_init_pud(), use_1G_block() [arch/arm64/mm/mmu.c] > For this situation, do you know how to reproduce it easily? Can you share your steps in detail? BTW: I did the test, but I didn't enter into the kernel code path because that condition was not met. # dmesg|grep -i huge [ 0.000000] Kernel command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.12.0-rc7+ root=/dev/mapper/rhel_gigabyte--r120--20-root ro arm-smmu.disable_bypass=n initcall_blacklist=gtdt_sbsa_gwdt_init iommu.passthrough=1 crashkernel=512M hugepagesz=1G hugepages=6 debug_pagealloc=on rd.lvm.lv=rhel_gigabyte-r120-20/root rd.lvm.lv=rhel_gigabyte-r120-20/swap [ 2.620634] HugeTLB registered 1.00 GiB page size, pre-allocated 6 pages Thanks. Lianbo > This problem can for instance be seen with vtop command, example: > > crash> vtop ffffffd988008000 > VIRTUAL PHYSICAL > ffffffd988008000 148008000 > > PAGE DIRECTORY: ffffff9188c6c000 > PGD: ffffff9188c6cb30 => 68000140000711 > PMD: ffffffd980000200 => aa0003e2b9402fe1 > PAGE: 3e2b9400000 (2MB) > > PTE PHYSICAL FLAGS > aa0003e2b9402fe1 3e2b9402000 (VALID|USER|RDONLY|SHARED|AF|NG) > --- > arm64.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/arm64.c b/arm64.c > index 37aed07..4787fa6 100644 > --- a/arm64.c > +++ b/arm64.c > @@ -1260,11 +1260,14 @@ arm64_uvtop(struct task_context *tc, ulong uvaddr, physaddr_t *paddr, int verbos > #define PTE_TO_PHYS(pteval) (machdep->max_physmem_bits == 52 ? \ > (((pteval & PTE_ADDR_LOW) | ((pteval & PTE_ADDR_HIGH) << 36))) : (pteval & PTE_ADDR_LOW)) > > +#define PUD_TYPE_MASK 3 > +#define PUD_TYPE_SECT 1 > #define PMD_TYPE_MASK 3 > #define PMD_TYPE_SECT 1 > #define PMD_TYPE_TABLE 2 > #define SECTION_PAGE_MASK_2MB ((long)(~((MEGABYTES(2))-1))) > #define SECTION_PAGE_MASK_512MB ((long)(~((MEGABYTES(512))-1))) > +#define SECTION_PAGE_MASK_1GB ((long)(~((GIGABYTES(1))-1))) > > static int > arm64_vtop_2level_64k(ulong pgd, ulong vaddr, physaddr_t *paddr, int verbose) > @@ -1420,6 +1423,15 @@ arm64_vtop_3level_4k(ulong pgd, ulong vaddr, physaddr_t *paddr, int verbose) > if (!pgd_val) > goto no_page; > > + if ((pgd_val & PUD_TYPE_MASK) == PUD_TYPE_SECT) { > + ulong sectionbase = (pgd_val & SECTION_PAGE_MASK_1GB) & PHYS_MASK; > + if (verbose) { > + fprintf(fp, " PAGE: %lx (1GB)\n\n", sectionbase); > + arm64_translate_pte(pgd_val, 0, 0); > + } > + *paddr = sectionbase + (vaddr & ~SECTION_PAGE_MASK_1GB); > + return TRUE; > + } > /* > * #define __PAGETABLE_PUD_FOLDED > */ > -- 2.17.1

4 years

3
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Crash-utility April 2021