Hi Kazu, On Thu, Feb 01, 2024 at 08:29:01AM +0000, HAGIO KAZUHITO(萩尾 一仁) wrote: > 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 sample vmlinux and vmcore. > > I'm still reviewing the patches and "gdb bt" looks good to me, but it > looks like "gdb info threads" calls GETBUF() too much. and the next > same command fails. > > $ crash-ppc64 vmlinux vmcore > ... > crash-ppc64> gdb info threads > Id Target Id Frame > 1 CPU 0 plpar_hcall_norets_notrace () at arch/powerpc/platforms/pseries/hvCall.S:114 > 2 CPU 1 plpar_hcall_norets_notrace () at arch/powerpc/platforms/pseries/hvCall.S:114 > 3 CPU 2 plpar_hcall_norets_notrace () at arch/powerpc/platforms/pseries/hvCall.S:114 > ... > 42 CPU 41 plpar_hcall_norets_notrace () at arch/powerpc/platforms/pseries/hvCall.S:114 > * 43 CPU 42 0xc00000000005ae44 in crash_fadump (regs=0x0, str=0xc000000002c0a6a0 <buf> "sysrq triggered crash") at arch/powerpc/kernel/fadump.c:728 > 44 CPU 43 plpar_hcall_norets_notrace () at arch/powerpc/platforms/pseries/hvCall.S:114 > ... > 54 CPU 53 plpar_hcall_norets_notrace () at arch/powerpc/platforms/pseries/hvCall.S:114 > 55 CPU 54 plpar_hcall_norets_notrace () at arch/powerpc/platforms/pseries/hvCall.S:114 > buf_1K_used: 50 > buf_2K_used: 10 > buf_4K_used: 2 > buf_8K_used: 0 > buf_32K_used: 3 > ... > malloc_bp[1997]: 8f3db90 > malloc_bp[1998]: 8f41ba0 > malloc_bp[1999]: 8f45bb0 > smallest: 24 > largest: 2883584 > embedded: 2003 > max_embedded: 2003 > mallocs: 2162 > frees: 162 > reqs/total: 2228/41701642 > average size: 18717 > gdb: cannot allocate any more memory! > crash-ppc64> > crash-ppc64> gdb info threads > ui-out.c:357: internal-error: tables cannot be nested; table_begin found before previous table_end. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Quit this debugging session? (y or n) > > > Doesn't this happen on ppc64 machines? > There might be lack of FREEBUF() somewhere. Thanks for the hint about missing FREEBUF, yes, a FREEBUF was missing in `ppc64_get_cpu_reg`, where the stack memory was allocated a buffer, everytime `ppc64_get_cpu_reg` was called. I have fixed in v7. I don't know why I didn't hit it before. Thanks, Aditya Gupta > > Thanks, > Kazu -- Crash-utility mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxxxxxx https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/ Contribution Guidelines: https://github.com/crash-utility/crash/wiki
