May 2024 - Crash-utility - Crash Utility List Archives

Re: [PATCH] arm64: section_size_bits compatible with macro definitions

by Lianbo Jiang

Hi, Guanyou Thank you for the patch. On 4/17/24 19:55, devel-request(a)lists.crash-utility.osci.io wrote: > Date: Wed, 17 Apr 2024 19:55:40 +0800 > From: Guanyou Chen<chenguanyou9338(a)gmail.com> > Subject: [Crash-utility] [PATCH] arm64: section_size_bits compatible > with macro definitions > To:k-hagio-ab@nec.com,devel@lists.crash-utility.osci.io, Lianbo > <lijiang(a)redhat.com> > Message-ID: > <CAHS3RMXw5Ya44Nc+fFQqXdwYvHcDnq1RG7-zPpbqTOPoCb0YUw(a)mail.gmail.com> > Content-Type: multipart/mixed; boundary="000000000000492e3b0616498933" > > --000000000000492e3b0616498933 > Content-Type: multipart/alternative; boundary="000000000000492e390616498931" > > --000000000000492e390616498931 > Content-Type: text/plain; charset="UTF-8" > > Hi Kazu, > > Compatible with google android GKI changes, > SECTION_SIZE_BITS = 27 when defined 4K_PAGES or 16K_PAGES. > SECTION_SIZE_BITS = 29 when defined 64K_PAGES. > > Link: > https://lore.kernel.org/lkml/15cf9a2359197fee0168f820c5c904650d07939e.161... > Link: > https://lore.kernel.org/all/43843c5e092bfe3ec4c41e3c8c78a7ee35b69bb0.1611... > > See: > https://cs.android.com/android/_/android/kernel/common/+/673e9ab6b64f9811... > Before android-12-gki: > crash> help -m | grep section_size_bits > section_size_bits: 30 > > The first PFN error, the physical address should be 0x40000000. > crash> kmem -p > PAGE PHYSICAL MAPPING INDEX CNT FLAGS > ffffffff06e00000 200000000 ffffff80edf4fa12 ffffffff070f3640 1 > 4000000000002000 private > > After android-12-gki: > crash> help -m | grep section > section_size_bits: 27 > > crash> kmem -p > PAGE PHYSICAL MAPPING INDEX CNT FLAGS > fffffffeffe00000 40000000 0 0 1 1000 reserved The macro SECTION_SIZE_BITS has changed since kernel version 5.12, see: kernel commit: f0b13ee23241 ("arm64/sparsemem: reduce SECTION_SIZE_BITS") crash commit: 8246dce99dd2 ("arm64: Update SECTION_SIZE_BITS for kernels >= 5.12") And later kernel exported the SECTION_SIZE_BITS in kernel version v5.13-rc7~20^2~10: kernel commit: 4f5aecdff25f ("crash_core, vmcoreinfo: append 'SECTION_SIZE_BITS' to vmcoreinfo") Crash-utility also reads the value from vmcoreinfo as below: if (arm64_get_vmcoreinfo(&machdep->section_size_bits, "NUMBER(SECTION_SIZE_BITS)", NUM_DEC)) So I'm wondering if this issue occurs on older kernels(e.g. 5.12 or earlier), and probably introduced some latest kernel patches(such as kernel commit f0b13ee23241) to the old kernel. Just want to confirm this. > Signed-off-by: chenguanyou<chenguanyou(a)xiaomi.com> > --- > arm64.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/arm64.c b/arm64.c > index e36c723..50e22ea 100644 > --- a/arm64.c > +++ b/arm64.c > @@ -1629,7 +1629,16 @@ arm64_get_section_size_bits(void) > if ((ret = get_kernel_config("CONFIG_HOTPLUG_SIZE_BITS", > &string)) == IKCONFIG_STR) > machdep->section_size_bits = atol(string); > } > - } > + > + // arm64: reduce section size for sparsemem > + if ((ret = get_kernel_config("CONFIG_ARM64_4K_PAGES", NULL)) == > IKCONFIG_Y > + || (ret = get_kernel_config("CONFIG_ARM64_16K_PAGES", > NULL)) == IKCONFIG_Y) > + machdep->section_size_bits = _SECTION_SIZE_BITS_5_12; > + // arm64/sparsemem: reduce SECTION_SIZE_BITS > + else if ((ret = get_kernel_config("CONFIG_ARM64_64K_PAGES", NULL)) > == IKCONFIG_Y) > + machdep->section_size_bits = _SECTION_SIZE_BITS_5_12_64K; > + > + } The IKCONFIG may not be set for many distributions, but this looks like it works well in your cases. Thanks. Lianbo > if (CRASHDEBUG(1)) > fprintf(fp, "SECTION_SIZE_BITS: %ld\n", machdep->section_size_bits); > -- 2.39.0

3 months, 4 weeks

2
1
0 / 0

Re: [PATCH] remove struct zspage_5_17 and use union to resolve issue

by Lianbo Jiang

Hi, Chenguanyou Thank you for the patch. Can you post the v2 with plain text? Or did I miss anything? Thanks Lianbo On 4/24/24 20:13, devel-request(a)lists.crash-utility.osci.io wrote: > Date: Wed, 24 Apr 2024 17:23:55 +0800 > From: Guanyou Chen<chenguanyou9338(a)gmail.com> > Subject: [Crash-utility] [PATCH] remove struct zspage_5_17 and use > union to resolve issue > To: Lianbo<lijiang(a)redhat.com>,devel(a)lists.crash-utility.osci.io, > k-hagio-ab(a)nec.com > Message-ID: > <CAHS3RMVjQ7bBG4cnrdzswsAGrNeRW30AaPtVzXNJ3XHHyb+8+A(a)mail.gmail.com> > Content-Type: multipart/mixed; boundary="00000000000072ca390616d43bfc" > > --00000000000072ca390616d43bfc > Content-Type: multipart/alternative; boundary="00000000000072ca370616d43bfa" > > --00000000000072ca370616d43bfa > Content-Type: text/plain; charset="UTF-8" > > Hi LianBo > > We don't need struct zspage_5_17. > > --- > defs.h | 32 +++++++++++++++----------------- > diskdump.c | 15 ++++++--------- > 2 files changed, 21 insertions(+), 26 deletions(-)

3 months, 4 weeks

2
2
0 / 0

Re: [PATCH v5 ] Adding the zram decompression algorithm "lzo-rle"

by Lianbo Jiang

Hi, Yulong Thank you for the update. The v5 looks good to me. Applied: https://github.com/crash-utility/crash/commit/a584e9752fb2198c7f6d0130d8a... On 4/28/24 15:20, devel-request(a)lists.crash-utility.osci.io wrote: > Date: Sun, 28 Apr 2024 07:20:01 +0000 > From: Yulong TANG 汤玉龙<yulong.tang(a)nio.com> > Subject: [Crash-utility] [PATCH v5 ] Adding the zram decompression > algorithm "lzo-rle" > To:"devel(a)lists.crash-utility.osci.io" > <devel(a)lists.crash-utility.osci.io> > Message-ID: <BJSPR01MB0721C50C8B0ECF8126862965E914A(a)BJSPR01MB0721.CHN > PR01.prod.partner.outlook.cn> > Content-Type: multipart/mixed; boundary="_004_BJSPR01MB0721C50C8B0ECF > 8126862965E914ABJSPR01MB0721CHNP_" > > --_004_BJSPR01MB0721C50C8B0ECF8126862965E914ABJSPR01MB0721CHNP_ > Content-Type: multipart/alternative; > boundary="_000_BJSPR01MB0721C50C8B0ECF8126862965E914ABJSPR01MB0721CHNP_" > > --_000_BJSPR01MB0721C50C8B0ECF8126862965E914ABJSPR01MB0721CHNP_ > Content-Type: text/plain; charset="utf-8" > Content-Transfer-Encoding: base64 BTW: I got some encoding issues as below: SW4gTGludXggNS4xLCB0aGUgWlJBTSBibG9jayBkcml2ZXIgaGFzIGNoYW5nZWQgaXRzIGRlZmF1 bHQgY29tcHJlc3NvciBmcm9tICJsem8iIHRvICJsem8tcmxlIiB0byBlbmhhbmNlIExaTyBjb21w cmVzc2lvbiBzdXBwb3J0LiBIb3dldmVyLCBjcmFzaCBkb2VzIG5vdCBzdXBwb3J0IHRoZSBpbXBy ... And it's not plain text... Could you please check your email configuration? I haven't seen the similar issues from other people's emails. Just a guess. Thanks Lianbo

4 months

2
1
0 / 0

[Question] crash-8.0.5 invalid to parse the assembly code by dis cmd for ARM64 crash dump

by qiwu.chen＠transsion.com

Dear sirs, I found a bug for crash-8.0.5 that I failed to parse the assembly code by dis cmd for ARM64 crash dump: $ crash vmlinux dump.202403061305 -d 1 KERNEL: vmlinux [TAINTED] DUMPFILE: dump.202403061305 [PARTIAL DUMP] CPUS: 4crash: get_cpus_online: online: 4 DATE: Wed Mar 6 21:04:30 CST 2024 UPTIME: 2135039823346 days, 00:18:07 LOAD AVERAGE: 0.32, 0.40, 0.17 TASKS: 93 NODENAME: benshushu RELEASE: 5.15.0+ VERSION: #1 SMP Tue Mar 5 16:54:41 CST 2024 MACHINE: aarch64 (unknown Mhz) MEMORY: 1 GB PANIC: "Unable to handle kernel paging request at virtual address ffff800809102430" PID: 494 COMMAND: "bash" TASK: ffff000007d11a80 [THREAD_INFO: ffff000007d11a80] CPU: 0 STATE: TASK_RUNNING (PANIC) crash> bt PID: 494 TASK: ffff000007d11a80 CPU: 0 COMMAND: "bash" 0: ffff80001022400c (crash_kexec) #0 [ffff000007ce34d0] crash_kexec at ffff800010224008 #1 [ffff000007ce3570] die at ffff800010030038 #2 [ffff000007ce35e0] die_kernel_fault at ffff80001005d8e8 #3 [ffff000007ce3610] __do_kernel_fault at ffff80001005dbf4 #4 [ffff000007ce3650] do_bad_area at ffff80001005de14 #5 [ffff000007ce36b0] do_translation_fault at ffff800011172f84 #6 [ffff000007ce3700] do_mem_abort at ffff80001005e220 #7 [ffff000007ce3760] el1_abort at ffff800011162210 #8 [ffff000007ce3790] el1h_64_sync_handler at ffff80001116243c #9 [ffff000007ce38f0] el1h_64_sync at ffff8000100111dc ...... crash> dis do_mem_abort crash> dis -x ffff80001005e220 -r 8 0xffff80001005e184 <do_mem_abort>: crash> dis do_mem_abort 0xffff80001005e184 <do_mem_abort>: crash> dis do_translation_fault 0xffff800011172ed4 <do_translation_fault>: There is no problem for crash-8.0.4: crash> dis do_mem_abort 0xffff80001005e184 <do_mem_abort>: mov x9, x30 0xffff80001005e188 <do_mem_abort+4>: nop 0xffff80001005e18c <do_mem_abort+8>: stp x29, x30, [sp, #-96]! 0xffff80001005e190 <do_mem_abort+12>: mov x29, sp ...... There must be some change corrupted the ARM64 dis function. Please help look at the issue. Thanks

4 months

2
5
0 / 0

[Question] About BITS_PER_LONG

by Guanyou Chen

Hi Tao, Lianbo BITS_PER_LONG should equals 32 when on host x86_64 build target arm ? diff --git a/defs.h b/defs.h index 01f316e..4d8ebc9 100644 --- a/defs.h +++ b/defs.h @@ -4842,7 +4842,11 @@ struct machine_specific { #define UNINITIALIZED (BADVAL) #define BITS_PER_BYTE (8) -#define BITS_PER_LONG (BITS_PER_BYTE * sizeof(long)) +#ifdef _64BIT_ +#define BITS_PER_LONG (64) +#else +#define BITS_PER_LONG (32) +#endif

4 months

1
0
0 / 0

[PATCH] remove struct zspage_5_17 and use union to resolve issue

by Guanyou Chen

Hi LianBo We don't need struct zspage_5_17. --- defs.h | 32 +++++++++++++++----------------- diskdump.c | 15 ++++++--------- 2 files changed, 21 insertions(+), 26 deletions(-) diff --git a/defs.h b/defs.h index 3cb8e63..01f316e 100644 --- a/defs.h +++ b/defs.h @@ -7407,28 +7407,26 @@ ulong try_zram_decompress(ulonglong pte_val, unsigned char *buf, ulong len, ulon #define SECTORS_PER_PAGE (1 << SECTORS_PER_PAGE_SHIFT) struct zspage { - struct { - unsigned int fullness : 2; - unsigned int class : 9; - unsigned int isolated : 3; - unsigned int magic : 8; + union { + unsigned int flag_bits; + struct { + unsigned int fullness : 2; + unsigned int class : 9; + unsigned int isolated : 3; + unsigned int magic : 8; + } v0; + struct { + unsigned int huge : 1; + unsigned int fullness : 2; + unsigned int class : 9; + unsigned int isolated : 3; + unsigned int magic : 8; + } v5_17; }; unsigned int inuse; unsigned int freeobj; }; -struct zspage_5_17 { - struct { - unsigned int huge : 1; - unsigned int fullness : 2; - unsigned int class : 9; - unsigned int isolated : 3; - unsigned int magic : 8; - }; - unsigned int inuse; - unsigned int freeobj; -}; - /* * makedumpfile.c */ diff --git a/diskdump.c b/diskdump.c index 3ae7bf2..a928a0e 100644 --- a/diskdump.c +++ b/diskdump.c @@ -2819,7 +2819,6 @@ zram_object_addr(ulong pool, ulong handle, unsigned char *zram_buf) { ulong obj, off, class, page, zspage; struct zspage zspage_s; - struct zspage_5_17 zspage_5_17_s; physaddr_t paddr; unsigned int obj_idx, class_idx, size; ulong pages[2], sizes[2]; @@ -2833,15 +2832,13 @@ zram_object_addr(ulong pool, ulong handle, unsigned char *zram_buf) readmem(page + OFFSET(page_private), KVADDR, &zspage, sizeof(void *), "page_private", FAULT_ON_ERROR); + readmem(zspage, KVADDR, &zspage_s, sizeof(struct zspage), "zspage", FAULT_ON_ERROR); if (VALID_MEMBER(zspage_huge)) { - readmem(zspage, KVADDR, &zspage_5_17_s, - sizeof(struct zspage_5_17), "zspage_5_17", FAULT_ON_ERROR); - class_idx = zspage_5_17_s.class; - zs_magic = zspage_5_17_s.magic; + class_idx = zspage_s.v5_17.class; + zs_magic = zspage_s.v5_17.magic; } else { - readmem(zspage, KVADDR, &zspage_s, sizeof(struct zspage), "zspage", FAULT_ON_ERROR); - class_idx = zspage_s.class; - zs_magic = zspage_s.magic; + class_idx = zspage_s.v0.class; + zs_magic = zspage_s.v0.magic; } if (zs_magic != ZSPAGE_MAGIC) @@ -2887,7 +2884,7 @@ zram_object_addr(ulong pool, ulong handle, unsigned char *zram_buf) out: if (VALID_MEMBER(zspage_huge)) { - if (!zspage_5_17_s.huge) + if (!zspage_s.v5_17.huge) return (zram_buf + ZS_HANDLE_SIZE); } else { readmem(page, KVADDR, &obj, sizeof(void *), "page flags", FAULT_ON_ERROR); -- 2.39.0

4 months

2
4
0 / 0

[PATCH] arm64: section_size_bits compatible with macro definitions

by Guanyou Chen

Hi Kazu, Compatible with google android GKI changes, SECTION_SIZE_BITS = 27 when defined 4K_PAGES or 16K_PAGES. SECTION_SIZE_BITS = 29 when defined 64K_PAGES. Link: https://lore.kernel.org/lkml/15cf9a2359197fee0168f820c5c904650d07939e.161... Link: https://lore.kernel.org/all/43843c5e092bfe3ec4c41e3c8c78a7ee35b69bb0.1611... See: https://cs.android.com/android/_/android/kernel/common/+/673e9ab6b64f9811... Before android-12-gki: crash> help -m | grep section_size_bits section_size_bits: 30 The first PFN error, the physical address should be 0x40000000. crash> kmem -p PAGE PHYSICAL MAPPING INDEX CNT FLAGS ffffffff06e00000 200000000 ffffff80edf4fa12 ffffffff070f3640 1 4000000000002000 private After android-12-gki: crash> help -m | grep section section_size_bits: 27 crash> kmem -p PAGE PHYSICAL MAPPING INDEX CNT FLAGS fffffffeffe00000 40000000 0 0 1 1000 reserved Signed-off-by: chenguanyou <chenguanyou(a)xiaomi.com> --- arm64.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/arm64.c b/arm64.c index e36c723..50e22ea 100644 --- a/arm64.c +++ b/arm64.c @@ -1629,7 +1629,16 @@ arm64_get_section_size_bits(void) if ((ret = get_kernel_config("CONFIG_HOTPLUG_SIZE_BITS", &string)) == IKCONFIG_STR) machdep->section_size_bits = atol(string); } - } + + // arm64: reduce section size for sparsemem + if ((ret = get_kernel_config("CONFIG_ARM64_4K_PAGES", NULL)) == IKCONFIG_Y + || (ret = get_kernel_config("CONFIG_ARM64_16K_PAGES", NULL)) == IKCONFIG_Y) + machdep->section_size_bits = _SECTION_SIZE_BITS_5_12; + // arm64/sparsemem: reduce SECTION_SIZE_BITS + else if ((ret = get_kernel_config("CONFIG_ARM64_64K_PAGES", NULL)) == IKCONFIG_Y) + machdep->section_size_bits = _SECTION_SIZE_BITS_5_12_64K; + + } if (CRASHDEBUG(1)) fprintf(fp, "SECTION_SIZE_BITS: %ld\n", machdep->section_size_bits); -- 2.39.0 Thanks, Guanyou.Chen

4 months, 1 week

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Crash-utility May 2024