Hi Tao,
thank you for the patches.
On 2023/11/02 21:09, Tao Liu wrote:
> The address range may overlap for kernel modules global block vector,
> for example:
>
> module compunit_symtab block start block end
> floppy floppy.c c0092000 c00a4fa6
>
ion/symbols of modules..
Thanks,
Kazu
On 2023/11/07 17:20, Tao Liu wrote:
> Hi Kazu,
>
> On Tue, Nov 7, 2023 at 1:07 PM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>>
>> Hi Tao,
>>
>> thank you for the patches.
>>
>> On 2023/11/02 21:09, Tao Liu wrote:
>
On 2023/11/06 14:04, HAGIO KAZUHITO(萩尾 一仁) wrote:
> On 2023/11/03 18:45, Shijie Huang wrote:
>
>>> +summary_inode_page(ulong page)
>>> +{
>>> + int node;
>>> +
>>> + if (!is_page_ptr(page, NULL))
>>> + err
On 2023/11/03 18:45, Shijie Huang wrote:
>> +summary_inode_page(ulong page)
>> +{
>> + int node;
>> +
>> + if (!is_page_ptr(page, NULL))
>> + error(FATAL, "Invalid inode page(0x%lx)\n", page);
I don't remember the detail of xarray, but my cacheutils extension
module
On 2023/11/10 12:15, Tao Liu wrote:
>> If a module already does not have its init memory range, it might be
>> a bit better to not specify "-s .init.text " to add-symbol-file..
>>
>
> Thanks a lot for finding the root cause. My patch is just a
> work-around, and I think your "trial" patch is
On 2023/11/08 19:00, lijiang wrote:
>> Then "files -p" option also emits the same error?
>>
>>
> Yes. It has the same error:
> crash> files -p 8ea84c130938
> INODENRPAGES
> 8ea84c13093862527
>
>PAGEPHYSICAL MAPPING INDEX CNT FLAGS
>
On 2023/11/08 17:16, HAGIO KAZUHITO(萩尾 一仁) wrote:
> On 2023/11/08 12:01, HAGIO KAZUHITO(萩尾 一仁) wrote:
>> Hi Tao,
>>
>> thank you for the information.
>>
>> I'm looking into it, I noticed that the unexpected symbol
>> "floopy_module_init"
>
Hi Edward,
thank you for the patch.
On 2023/12/26 2:38, Edward Chron wrote:
> Subject: [PATCH] crash add log dmesg PRINTK_CALLER id support
please update the prefix like "[PATCH v2]" when you revise a patch so
that we can determine which is the latest.
> From: Edward Chron
>
> Submission
On 2024/01/22 21:33, Aditya Gupta wrote:
> Hello Lianbo,
>
> On 22/01/24 15:18, Lianbo Jiang wrote:
>> Hi, Aditya
>>
>> On 1/22/24 17:24, Aditya Gupta wrote:
>>
>>> Hi Lianbo,
>>>
>>> Just a ping for the series. Any pending reviews for upstreaming it ?
Hi Aditya,
sorry for the delay.
Is it
On 2024/02/05 17:20, tianming.w...@unisoc.com wrote:
> crash_arm64_v8.0.4++> set debug 1
> debug: 1
> crash_arm64_v8.0.4++> mod -s sysdump
> sysdump: module symbols are already loaded
then please delete it first.
crash> mod -d sysdump
crash> set debug 1
crash> mod -s sysdump
Thanks,
Kazu
>
On 2024/02/06 6:18, nilayva...@google.com wrote:
>> On 2024/01/30 9:24, nilayvaish(a)google.com wrote:
>>
>> thanks for the information.
>>
>> I can see that there is the orc_header symbol and data also in a vmcore,
>> so maybe it can be read easily:
>>
>> crash> whatis orc_header
>> const u8
Hi Aditya,
thanks for the update, 'info threads' worked well.
On 2024/02/05 15:36, Aditya Gupta wrote:
> Currently, both crash context and gdb's current thread context were
> pretty independent, and could be different, for example, crash commands
> might be working on thread 6 (CPU 5), but GDB
On 2024/02/05 15:36, Aditya Gupta wrote:
> @@ -1880,7 +1880,7 @@ cmd_set(void)
> error(INFO, "no panic task found!\n");
> return;
> }
> - set_context(tt->panic_task, NO_PID);
> +
On 2024/02/05 16:20, tianming.w...@unisoc.com wrote:
>
> After raising the loglevel to 7, enter ” whatis sysdump_panic_event“ and an
> error will be reported.
> crash_arm64_v8.0.4++> sym sysdump_panic_event
> ff384 (t) sysdump_panic_event []
> crash_arm64_v8.0.4++> whatis
On 2024/02/05 15:43, tianming.w...@unisoc.com wrote:
> Hi kazu
>
> it looks ok（I added xxx myself for safety）
>
> crash_arm64_v8.0.4++> sym sysdump_panic_event
> ffx384 (t) sysdump_panic_event [xxx]
> crash_arm64_v8.0.4++> whatis sysdump_panic_event
> int sysdump_panic_event(struct
On 2024/01/30 17:08, 王天明 (Tianming Wang) wrote:
> Hi
>
> I use crash8.0.4_arm64 to parse the ramdump of android15-k6.6, load the
> symbol of ko,
> and disassemble the functions in ko through the "dis -lx" command.
> I can get the assembly instructions, but I cannot get the corresponding
>
On 2024/01/30 9:24, nilayva...@google.com wrote:
> Folks
>
> The Linux kernel commit b9f174c811e3ae4ae8959dc57e6adb9990e913f4
> (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b9f174c811e3ae4ae8959dc57e6adb9990e913f4)
> added an ELF section for the ORC version
On 2024/02/08 20:21, Aditya Gupta wrote:
> Hi Kazu,
>
> On Thu, Feb 08, 2024 at 08:40:26AM +, HAGIO KAZUHITO(萩尾 一仁) wrote:
>> <...snip...>
>>
>>> Currently, both crash context and gdb's current thread context were
>>> pretty independent, and co
On 2024/02/09 22:15, Tao Liu wrote:
> On Fri, Feb 02, 2024 at 07:04:14AM +, HAGIO KAZUHITO(萩尾 一仁) wrote:
>> Hi Aditya,
>>
>> Thank you for the work, it looks nicely done to me, except for the "info
>> threads" issue and the style of the gdb patch.
>&g
On 2023/12/14 16:15, Huang Shijie wrote:
> If the kernel exports the vmmemap then we can use that symbol in
> crash to optimize access. vmmemap is just an array of page structs
> after all.
>
> This patch tries to:
>1.) Get the "vmemmap" from the vmcore file.
>If we can use the
On 2023/12/15 11:44, Li Zhijian wrote:
> -l option has existed when crash git project initialization, but its
> help message was not accurate(extra arguments a|i|ic|id was missing).
>
> In addition, these symbols required by -l option was for the very *old old*
> kernels, at least >= 2.6 don't
On 2023/12/01 16:40, Li Zhijian wrote:
> Per the soucde code, '-l' requires extra arguments but it's missing in
> documentation.
>
> Signed-off-by: Li Zhijian
> ---
> help.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/help.c b/help.c
> index
Hi chenqiwu,
Thank you for the update.
The patch can be applied but there are several comments below,
I tweaked the patch on my end. Could you test the attached patch?
Lianbo, please review the attached one.
On 2023/12/22 12:30, qiwu.c...@transsion.com wrote:
> Kernel commit
On 2023/12/25 12:56, Ming Wang wrote:
> Hi, Kazu
>
> Thanks for your review. Sorry, I forgot to send to the mailing list. So send
> it again.
>
> On 12/13/23 12:57, HAGIO KAZUHITO(萩尾 一仁) wrote:
>> Hi Ming,
>>
>> sorry for the delay.
>>
>> On 202
On 2023/12/25 16:31, Lianbo Jiang wrote:
> On 12/15/23 14:57, devel-requ...@lists.crash-utility.osci.io wrote:
>
>> Date: Fri, 15 Dec 2023 10:44:21 +0800
>> From: Li Zhijian
>> Subject: [Crash-utility] [PATCH v2] help.c: Remove kmem -l help
>> messages
>> To:devel@lists.crash-utility.osci.io
On 2023/12/08 0:54, Alexander Gordeev wrote:
> Rework VTOP and PTOV macros to reflect the future
> uncoupling of physical and virtual address spaces
> in kernel. Existing versions are not affected.
>
> Signed-off-by: Alexander Gordeev
For the series with the 3/3 v3,
Acked-by: Kazuhito Hagio
On 2023/12/07 21:57, lijiang wrote:
>>> It indicates that the attached patch may not work well between kernel
>>> 4.11 and 5.12, is it possible to encounter the similar issue(the
>>> nr_swapper_spaces may be optimized away)?
>>
>> I have not noticed any problems with the attached patch on
>>
On 2023/11/08 10:39, Ming Wang wrote:
> Changes between v1 and v2:
> - Simplified the LoongArch64 gdb's backport patch and appended it to the
> gdb-10.2.patch.
> - Add building the loongarch crash binary on an X86 64 host support.
> - Fix offset_table format issues.
> - Move private definitions
Hi Ming,
sorry for the delay.
On 2023/11/08 10:39, Ming Wang wrote:
> @@ -512,6 +527,10 @@ get_current_configuration(struct supported_gdb_version
> *sp)
> (target_data.target != MIPS64))
> arch_mismatch(sp);
>
> + if
On 2023/12/12 19:20, Song Shuai wrote:
> With the patch we can get full dump of "struct elf_prstatus" in 'help -n':
>
> ```
> crash> help -n
>
> Elf64_Nhdr:
> n_namesz: 5 ("CORE")
> n_descsz: 376
> n_type: 1 (NT_PRSTATUS)
>
On 2023/12/26 10:19, Tao Liu wrote:
> Previously the value of bt->bptr is not checked, which may led to a
> wrong prev_sp and framesize. As a result, bt->stackbuf[] will be
> accessed out of range, and segfault.
>
> Before:
> crash> set debug 1
> crash> bt
> ...snip...
> --- ---
> #8
On 2023/12/26 21:21, Lianbo Jiang wrote:
> On 12/25/23 15:15, HAGIO KAZUHITO(萩尾 一仁) wrote:
>
>> Hi chenqiwu,
>>
>> Thank you for the update.
>>
>> The patch can be applied but there are several comments below,
>> I tweaked the patch on my end. Could
On 2023/12/26 20:55, Lianbo Jiang wrote:
> On 12/26/23 14:43, devel-requ...@lists.crash-utility.osci.io wrote:
>
>> Date: Tue, 26 Dec 2023 06:42:55 +
>> From: HAGIO KAZUHITO(萩尾 一仁)
>> Subject: [Crash-utility] Re: [PATCH] x86_64: check bt->bptr before
>> c
On 2023/12/27 18:12, qiwu.c...@transsion.com wrote:
> Hi Kazu,
> Thanks for your professional review.
> I test the attached patch, it's fine to load the crash dump enabled MTE.
Thank you for testing, applied.
https://github.com/crash-utility/crash/commit/edb2bd52885ccc2fbe3e0825efe0ac55951a7710
Thanks, applied.
Kazu
On 2023/12/19 18:36, Lianbo Jiang wrote:
> Hi, Song
>
> Thank you for the patch series.
>
> On 12/13/23 09:57, devel-requ...@lists.crash-utility.osci.io wrote:
>
>> Date: Tue, 12 Dec 2023 18:20:50 +0800
>> From: Song Shuai
>> Subject: [Crash-utility] [PATCH V2 1/2]
On 2023/12/19 0:01, Huang Shijie wrote:
> If the kernel exports the vmmemap then we can use that symbol in
> crash to optimize access. vmmemap is just an array of page structs
> after all.
>
> This patch tries to:
>1.) Get the "vmemmap" from the vmcore file.
>If we can use the
On 2023/12/15 17:49, qiwu.c...@transsion.com wrote:
> Kernel commit 11167161e553d("kasan, arm64: implement HW_TAGS runtime")
> introduce a Hardware Tag-Based KASAN(MTE) mode for ARMv8.5 later CPUs, which
> uses the Top Byte Ignore (TBI) feature of arm64 CPUs to store a pointer tag
> in the top
On 2023/12/20 23:46, Lameter, Christopher wrote:
> On Mon, 18 Dec 2023, Huang Shijie wrote:
>
>> diff --git a/arm64.c b/arm64.c
>> index 57965c6..fc4ba64 100644
>> --- a/arm64.c
>> +++ b/arm64.c
>> @@ -117,6 +117,28 @@ static void arm64_calc_kernel_start(void)
>> ms->kimage_end = (sp ?
Resending to the new crash list address (without kexec list)
On 2023/12/04 19:50, Song Shuai wrote:
> With the patch we can get full dump of "struct elf_prstatus" in 'help -n':
>
> ```
> crash> help -n
>
> Elf64_Nhdr:
> n_namesz: 5 ("CORE")
> n_descsz: 376
>
Resending to the new crash list address (without kexec list)
On 2023/12/04 19:50, Song Shuai wrote:
> Same as the Linux commit f766f77a74f5 ("riscv/stacktrace: Fix
> stack output without ra on the stack top").
>
> When a function doesn't have a callee, then it will not
> push ra into the stack,
On 2023/12/11 19:28, Lianbo Jiang wrote:
> On 12/11/23 14:08, HAGIO KAZUHITO(萩尾 一仁) wrote:
>
>> On 2023/12/08 0:54, Alexander Gordeev wrote:
>>> Rework VTOP and PTOV macros to reflect the future
>>> uncoupling of physical and virtual address spaces
&g
On 2023/12/13 18:45, Song Shuai wrote:
> The patch introduces per-cpu overflow stacks for RISCV64 to let
> "bt" do backtrace on it and the 'help -m' command dispalys the
> addresss of each per-cpu overflow stack.
>
> TEST: a lkdtm DIRECT EXHAUST_STACK vmcore
>
> ```
> crash> bt
> PID: 1
On 2024/01/05 16:56, Lianbo Jiang wrote:
> On 1/4/24 11:46, Ming Wang wrote:
>
>> Hi, Lianbo
>>
>> On 1/3/24 17:57, Lianbo Jiang wrote:
>>> Hi, Ming
>>>
>>> Thank you for the update.
Ming Wang (10):
Add LoongArch64 framework code support
LoongArch64: Make the crash tool
Hi Lianbo,
sorry for the delay..
On 2023/11/29 21:37, lijiang wrote:
> On Wed, Nov 29, 2023 at 8:45 AM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>
>> On 2023/11/28 11:31, Lianbo Jiang wrote:
>>> Currently, the "bt pid" command may not print enough stack
On 2024/01/12 11:40, HAGIO KAZUHITO(萩尾 一仁) wrote:
> Hi Lianbo,
>
> sorry for the delay..
>
> On 2023/11/29 21:37, lijiang wrote:
>> On Wed, Nov 29, 2023 at 8:45 AM HAGIO KAZUHITO(萩尾 一仁)
>> wrote:
>>
>>> On 2023/11/28 11:31, Lianbo Jiang wrote:
>>
On 2024/01/15 14:13, HAGIO KAZUHITO(萩尾 一仁) wrote:
> On 2024/01/12 19:46, Lianbo Jiang wrote:
>
>>> Could I have a few additional information?:
>> Sure.
>>> - What is the kernel version? (e.g. 5.14.0-362.8.1.el9_3.x86_64)
>> I observed the current issue o
On 2024/01/12 19:46, Lianbo Jiang wrote:
>> Could I have a few additional information?:
> Sure.
>> - What is the kernel version? (e.g. 5.14.0-362.8.1.el9_3.x86_64)
> I observed the current issue on the kernel 5.14.0-283.rt14.283.el9.x86_64.
>> - What happens with the following patch?
>
> The
On 2024/01/16 17:23, Lianbo Jiang wrote:
> On 1/16/24 16:11, HAGIO KAZUHITO(萩尾 一仁) wrote:
>
>> On 2024/01/15 16:58, Lianbo Jiang wrote:
>>
>>>> --- a/x86_64.c
>>>> +++ b/x86_64.c
>>>> @@ -3342,6 +3342,13 @@ x86_64_print_stack_ent
On 2024/01/15 16:58, Lianbo Jiang wrote:
>> --- a/x86_64.c
>> +++ b/x86_64.c
>> @@ -3342,6 +3342,13 @@ x86_64_print_stack_entry(struct bt_info *bt, FILE
>> *ofp, int level,
>>
>> bt->call_target = name;
>>
>> + /*
>> + * The caller check below does not work correctly for
On 2024/01/04 10:20, Tao Liu wrote:
> Previously, to find a module symbol and its offset by an arbitrary address,
> all symbols within the module will be iterated by address ascending order
> until the last symbol with a smaller address been noticed.
>
> However if the address is not within the
org/linux-mm/20230918072955.2507221-5-r...@kernel.org/
Thanks,
Kazu
>
> Thanks,
>
> From: Matt Suiche
> Date: Wednesday, November 29, 2023 at 3:26 PM
> To: HAGIO KAZUHITO(萩尾 一仁) ,
> devel@lists.crash-utility.osci.io
> Subject: Re: [Crash-utility] Google Container OS a
.
Recent kernels have vmcoreinfo in /proc/kcore, maybe we can use the
KERNELOFFSET value instead of the module_load_offset symbol to determine
whether KASLR is enabled. I might try it when I have time.
Thanks,
Kazu
>
> *From: *HAGIO KAZUHITO(萩尾 一仁)
> *Date: *Wednesday, November 22, 2023
On 2023/11/28 11:31, Lianbo Jiang wrote:
> Currently, the "bt pid" command may not print enough stack trace and the
> remaining frames will be truncated on x86_64. For example:
>
> Without the patch:
>crash> bt 493113
>PID: 493113 TASK: ff2e34ecbd3ca2c0 CPU: 27 COMMAND:
20, 2023 at 2:16 PM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>>
>> On 2023/11/17 16:52, Tao Liu wrote:
>>
>>> For the stacktrace of "dis -rl", it calls dw2_expand_all_symtabs() to expand
>>> all symtable of the objfile, or "*.ko.debug" in our
On 2023/11/28 18:05, lijiang wrote:
>> There might be address overlap of one module's .init.text symbols and
>> another module's .text symbols. As a result, gdb fails to translate the
>> address to symbol name correctly:
>>
>> crash> sym -m virtio_blk | grep MODULE
>> c00a4000 MODULE
On 2023/11/30 17:26, Shijie Huang wrote:
> Hi Kazu,
>
> 在 2023/11/30 15:29, HAGIO KAZUHITO(萩尾 一仁) 写道:
>> On 2023/11/30 16:21, HAGIO KAZUHITO(萩尾 一仁) wrote:
>>> thanks for the patch.
>>>
>>> On 2023/11/28 12:41, Huang Shijie wrote:
>>>> If the
On 2023/11/30 17:37, Shijie Huang wrote:
>>> @@ -104,6 +104,20 @@ static void check_vmcoreinfo(void);
>>> static int is_pvops_xen(void);
>>> static int get_linux_banner_from_vmlinux(char *, size_t);
>>> +/* Return TRUE if we succeed, return FALSE on failure. */
>>> +bool
>>>
On 2023/11/30 22:05, 薛国伦 wrote:
> Hi kazu:
>
>
> 1. I found that vmlinux of kernel-6.1 did not have symbol nr_swapper_spaces
> but only have swapper_spaces
>
> Also check in GKI vmlinux, can not find nr_swapper_spaces
Hmm, upstream kernel 6.1 has it.
$ git show v6.1:mm/swap_state.c
struct
On 2023/11/28 23:57, Stephen Brennan wrote:
> Module symbol names can get overwritten by live patches or ksplice in
> odd corner cases, so that the pointer no longer points within the string
> buffer. Gracefully fallback to reading the string directly from the
> kernel image in these cases, to
On 2023/11/30 17:52, lijiang wrote:
> On Thu, Nov 30, 2023 at 3:56 PM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>
>> On 2023/11/30 0:31, Tao Liu wrote:
>>
>>>> And I did not see the debuginfo again(only one time):
>>>> gdb_get_line_number 7101
>>>&
On 2023/11/30 16:21, HAGIO KAZUHITO(萩尾 一仁) wrote:
> thanks for the patch.
>
> On 2023/11/28 12:41, Huang Shijie wrote:
>> If the kernel exports the vmmemap then we can use that symbol in
>> crash to optimize access. vmmemap is just an array of page structs
>> after
On 2023/11/29 22:17, 薛国伦 wrote:
> Hi lianbo:
>
>
> I have a bug fixed need to merge to crash-utility which patch in attachment.
>
>
> It can obviously see that kmem -i show memory info of system.
> But CACHED have wrong output for add up size of cached memory.
>
> The reason of this bug is:
>
On 2023/11/28 12:41, Huang Shijie wrote:
> Add get_value_vmcore() to get the symbol value for @name.
>
> Also add macro GET_SYM to simplify the code.
>
> Signed-off-by: Huang Shijie
> ---
> defs.h | 1 +
> kernel.c | 85 +++-
> 2 files
thanks for the patch.
On 2023/11/28 12:41, Huang Shijie wrote:
> If the kernel exports the vmmemap then we can use that symbol in
> crash to optimize access. vmmemap is just an array of page structs
> after all.
>
> This patch tries to get the "vmemmap" from the vmcore file.
> If we can use the
On 2023/11/30 0:31, Tao Liu wrote:
>> And I did not see the debuginfo again(only one time):
>> gdb_get_line_number 7101
>>
>> Did I miss anything else?
Is there no case where sal.symtab == NULL after expansion?
I don't think of, but e.g. a wrong address is requested.
personally I'm ok with the
On 2023/11/21 9:07, HAGIO KAZUHITO(萩尾 一仁) wrote:
> On 2023/11/20 17:43, lijiang wrote:
>
>>> Lianbo, zram related offsets have some typos, irregular names and lack
>>> of "help -o" output. I made the patch 2/2 in this opportunity, could
>>> you rev
On 2023/11/23 11:21, lijiang wrote:
> Hi, Kazu
>
> On my side, I still got the following error after applying the patch:
>
> crash> files -p 8ea84c130938
> INODENRPAGES
> 8ea84c13093863375
>
>PAGEPHYSICAL MAPPING INDEX CNT FLAGS
>
On 2023/11/27 17:31, Tao Liu wrote:
> Hi,
>
> Recently I created a repo as crash-preview[1], which forks from
> upstream crash utility but provides a higher gdb version support. The
> purpose of the repo is to ease the work of gdb upgrading for upstream
> crash utility by doing the gdb upgrading
On 2023/11/28 10:42, lijiang wrote:
> On Mon, Nov 27, 2023 at 12:15 PM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>
>> On 2023/11/23 11:21, lijiang wrote:
>>> Hi, Kazu
>>>
>>> On my side, I still got the following error after applying the patch:
>>>
&g
On 2023/12/06 11:11, Stephen Brennan wrote:
> HAGIO KAZUHITO(萩尾 一仁) writes:
>
>> On 2023/11/28 23:57, Stephen Brennan wrote:
>>> Module symbol names can get overwritten by live patches or ksplice in
>>> odd corner cases, so that the pointer no longer point
On 2023/12/05 0:04, Alexander Gordeev wrote:
> +static bool is_read_proc_kcore(void)
> +{
> + struct stat kcore_stat, fd_stat;
> + int fd;
> + int rc;
> +
> + rc = stat("/proc/kcore", _stat);
> + if (rc)
> + return false;
> +
> + fd = REMOTE_MEMSRC() ?
On 2023/12/07 10:07, Lianbo Jiang wrote:
> On 12/6/23 11:45, 薛国伦 wrote:
>
>> Hi Lianbo:
>>
>>
>> the vmlinux i download from links:
>> https://ci.android.com/builds/submitted/11087000/kernel_aarch64/latest?hl=zh-cn
>>
>>
On 2023/12/07 16:57, Lianbo Jiang wrote:
>>> (gdb) p nr_swapper_spaces
>>> $4 =
>> Thank you folks, for the various information.
>>
>> Apparently the data of nr_swapper_spaces exists in the kernel, but its
>> symbol does not exist. I think this means that we cannot calculate the
>> number of
On 2024/01/24 15:57, HAGIO KAZUHITO(萩尾 一仁) wrote:
> Is it possible to upload a sample ppc64le vmcore and vmlinux somewhere
> off-list? I would like to check the behavior at my end, probably
> ppc64le vmcores can be processed by x86_64 crash for ppc64 vmcore.
Thanks for the sampl
On 2024/01/05 16:30, Aditya Gupta wrote:
> Currently, both crash context and gdb's current thread context were
> pretty independent, and could be different, for example, crash commands
> might be working on thread 6 (CPU 5), but GDB passthroughs will be
> working on thread 2 (CPU 1).
>
> This was
On 2024/01/05 16:30, Aditya Gupta wrote:
> Currently for most gdb_interface call with a non-null file pointer,
> GDB's output stream is replaced with the passed file pointer
>
> 'info threads', which is a gdb passthrough, fails to print all thread
> after support was added to get registers from
On 2024/01/05 16:30, Aditya Gupta wrote:
> Currently the output is like this ppc64le:
>
> crash> info threads
>Id Target Id Frame
>1CPU 0 in ?? ()
>2CPU 1 0xc0025d00 in ppc_panic_event
> (this=, event=, ptr=0x0) at
>
Hi Aditya,
Thank you for the work, it looks nicely done to me, except for the "info
threads" issue and the style of the gdb patch.
Hi Tao Liu,
I saw that you were interested in support for other architectures. I'd
like to test/support this also on x86_64 at the same time as ppc64 if
On 2024/01/05 16:30, Aditya Gupta wrote:
> Currently, gdb passthroughs of 'bt', 'frame', 'up', 'down', 'info
> locals' don't work. This is due to gdb not knowing the register values to
> unwind the stack frames
>
> Every gdb passthrough goes through `gdb_interface`. And then, gdb expects
>
On 2024/01/22 9:40, ech...@yahoo.com wrote:
> My post to the mailing list is visible now as Patchv2.
Yes, thanks for sending the v2.
It seems that your address (ech...@arista.com) is not a list member, so
emails are held until approved.
Thanks,
Kazu
--
Crash-utility mailing list --
On 2024/01/22 3:31, Edward Chron wrote:
> Submission to Project: crash
> Component: dmesg
> Files: kernel.c printk.c symbols.c help.c defs.h
> Code level patch applied against: 8.0.4++ - latest code pulled from
> https://github.com/crash-utility/crash.git
> crash Issue #164
> Patch
On 2024/01/29 18:49, Lianbo Jiang wrote:
> On 1/26/24 16:17, HAGIO KAZUHITO(萩尾 一仁) wrote:
>
>> Kernel commit 2eea9ce4310d ("mounts: keep list of mounts in an rbtree")
>> changed the structure that keeps the list of mounts to an rbtree.
>> Withou
On 2024/01/29 17:40, Lianbo Jiang wrote:
> Hi, Edward and Kazu
>
> Sorry for the late reply.
>
> On 1/22/24 16:02, devel-requ...@lists.crash-utility.osci.io wrote:
>> Date: Mon, 22 Jan 2024 08:01:50 +
>> From: HAGIO KAZUHITO(萩尾 一仁)
>> Subject: [Crash-uti
On 2024/01/22 16:28, Lianbo Jiang wrote:
> On 1/17/24 14:37, HAGIO KAZUHITO(萩尾 一仁) wrote:
>
>> On 2023/12/28 20:46, Ming Wang wrote:
>>> This patch set are for Crash-utility tool, it make crash tool support on
>>> loongarch64 architecture and the common commands
Kernel commit 2eea9ce4310d ("mounts: keep list of mounts in an rbtree")
changed the structure that keeps the list of mounts to an rbtree.
Without the patch, "mount" command fails with the following error:
crash> mount
mount: invalid structure member offset: mnt_namespace_list
On 2023/11/14 17:49, Tao Liu wrote:
> There is an issue that, for kernel modules loaded by mod -s/-S, "dis -rl"
> fails
> to display module's code line number data after execute "bt" cmd in crash.
>
> Without the patch:
> crsah> mod -S
> crash> bt
> PID: 1500 TASK: ff2bd8b093524000 CPU: 16
Download from:
https://crash-utility.github.io/
or
https://github.com/crash-utility/crash/releases
The GitHub master branch serves as a development branch that will
contain all patches that are queued for the next release:
$ git clone https://github.com/crash-utility/crash.git
On 2023/11/15 18:16, Tao Liu wrote:
>> a question, is "mod -S -r" a workaround for it?
>>
> Yes, it can work as expected with "mod -S -r", I didn't know "-r"
> parameter can trigger such symble expansion.
Thank you for the check.
>> I'm thinking that, if the current gdb's auto expansion is not
Hi Chengen,
thank you for the patch.
On 2023/11/09 11:54, Chengen Du wrote:
> A kernel commit 7ac07a26dea7 (zram: preparation for multi-zcomp support)
> in Linux replaces "compressor" with "comp_algs" in the zram struct.
> If not fixed, the issue triggers the following error:
>rd: WARNING:
Hi Chengen,
thank you for the update.
On 2023/11/17 12:45, Chengen Du wrote:
> A kernel commit 7ac07a26dea7 (zram: preparation for multi-zcomp support)
> in Linux replaces "compressor" with "comp_algs" in the zram struct.
> If not fixed, the issue triggers the following error:
>rd: WARNING:
On 2023/11/17 16:52, Tao Liu wrote:
> For the stacktrace of "dis -rl", it calls dw2_expand_all_symtabs() to expand
> all symtable of the objfile, or "*.ko.debug" in our case. However for
> the stacktrace of "bt", it doesn't expand all, but only a subset of symtable
> which is enough to find a
On 2023/11/17 18:10, johan.erlands...@sony.com wrote:
>>> Hi
>>> Sharing 3 changes for zram regarding swap cache handling. Please have a
>>> look.
>>>
>>> Subject: [PATCH 1/3] zram, swap cache missing page tree offset
>>> Subject: [PATCH 2/3] zram, swap cache entries are pointer to struct page
On 2023/11/10 2:33, johan.erlands...@sony.com wrote:
> Hi
> Sharing 3 changes for zram regarding swap cache handling. Please have a look.
>
> Subject: [PATCH 1/3] zram, swap cache missing page tree offset
> Subject: [PATCH 2/3] zram, swap cache entries are pointer to struct page
> Subject: [PATCH
On 2023/11/13 20:09, Lianbo Jiang wrote:
> Since the panic_on_oops is disabled, when getting a BUG hit in the code,
> the system continues and does not panic. However, a short time later, a
> hard lockup is hit and the system does panic. Even though the system
> panicked at hard lockup, the panic
On 2023/11/13 22:09, Tao Liu wrote:
>> A few slight comments:
>>
>> - lm->mod_init_module_ptr should has the address if available, this can
>> be used?
> Sorry I didn't get your point. The value here is only used as a flag
> to indicate if the .init. section has been freed or not. Since the
>
On 2023/11/14 17:32, Tao Liu wrote:
> There might be address overlap of one module's .init.text symbols and
> another module's .text symbols. As a result, gdb fails to translate the
> address to symbol name correctly:
>
> crash> sym -m virtio_blk | grep MODULE
> c00a4000 MODULE START:
On 2023/11/08 12:01, HAGIO KAZUHITO(萩尾 一仁) wrote:
> Hi Tao,
>
> thank you for the information.
>
> I'm looking into it, I noticed that the unexpected symbol "floopy_module_init"
> is in section .init.text. Crash side doesn't have the symbol info, probably
&g
On 2023/11/08 11:23, lijiang wrote:
> On Mon, Nov 6, 2023 at 1:33 PM Shijie Huang <
> shi...@amperemail.onmicrosoft.com> wrote:
>> 在 2023/11/6 13:16, HAGIO KAZUHITO(萩尾 一仁) 写道:
>>> On 2023/11/06 14:04, HAGIO KAZUHITO(萩尾 一仁) wrote:
>>>>
On 2023/11/11 11:39, Tao Liu wrote:
> Hi Kazu,
>
> On Fri, Nov 10, 2023 at 1:19 PM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>>
>> On 2023/11/10 12:15, Tao Liu wrote:
>>
>>>> If a module already does not have its init memory range, it might be
>>>> a bi
On 2023/11/20 17:43, lijiang wrote:
>> Lianbo, zram related offsets have some typos, irregular names and lack
>> of "help -o" output. I made the patch 2/2 in this opportunity, could
>> you review this too?
>>
>>
> Sorry for the late response, Kazu and Chengen.
>
> These two patches in
1 - 100 of 147 matches
Mail list logo
