Hi Tao, On 10/7/2025 1:11 AM, Tao Liu wrote: > On Tue, Sep 30, 2025 at 8:18 PM lijiang <[email protected]> wrote: >> >> On Tue, Sep 30, 2025 at 3:01 PM Mikhail Zaslonko <[email protected]> >> wrote: >>> >>> Hello, >>> >>> On 9/30/2025 4:53 AM, lijiang wrote: >>>> On Tue, Sep 30, 2025 at 2:18 AM Mikhail Zaslonko <[email protected]> >>>> wrote: >>>> >>>>> Hi Lianbo, >>>>> >>>>> It seems we have a problem printing disassembly blocks in the log after >>>>> this patch (at least on s390). >>>>> See number of empty lines printed below. >>>>> >>>> >>>> Can you try it with the following two patches? >>>> [1] >>>> https://www.mail-archive.com/[email protected]/msg01621.html >>> This patch is present on crash master, doesnt affect the issue. >>>> [2] >>>> https://www.mail-archive.com/[email protected]/msg01636.html >>>> >>> This one helps indeed! At least I do not se the blanks lines in my scenario. >>> BUT, if I use 'log -R' the blank lines are back again! >> >> >> Thanks for the information, Mikhail. >> Let me see how to debug this(although I can not reproduce it on s390x). > > I didn't reproduce the issue on my s390x machine either, maybe sharing > the vmcore to us can help.
I'm not sure I'm allowed to send this data outside. I think the problem takes place for the logs printed with pr_cont() by the kernel (e.g. show_code() of arch/s390/kernel/dis.c for printing disassembly as in my sample). > > Thanks, > Tao Liu > >> >> Thanks >> Lianbo >> >>> >>> >>>> >>>>> Before the patch: >>>>> [ 21.408784] Krnl GPRS: 000002aa3780c000 0000000000238c00 >>>>> 0000000015800000 0000000000001000 >>>>> [ 21.408787] 0000000008e30000 00000000b0001000 >>>>> 0000000000000000 0000000000000a55 >>>>> [ 21.408790] 0000000004c52300 000002aa3780c000 >>>>> 00000000084281d0 0000038000bfbd28 >>>>> [ 21.408794] 00000000075e9500 0000000004c52300 >>>>> 0000038000bfbbf0 0000038000bfbb90 >>>>> [ 21.408860] Krnl Code: 000000000e0acf48: c05fb0001000 llilf >>>>> %r5,2952794112 >>>>> 000000000e0acf4e: ec4100b30659 risbgn >>>>> %r4,%r1,0,179,6 >>>>> #000000000e0acf54: 0e24 mvcl >>>>> %r2,%r4 >>>>> >000000000e0acf56: a7280000 lhi >>>>> %r2,0 >>>>> 000000000e0acf5a: eb6ff0a80004 lmg >>>>> %r6,%r15,168(%r15) >>>>> 000000000e0acf60: b9140022 lgfr >>>>> %r2,%r2 >>>>> 000000000e0acf64: 07fe bcr >>>>> 15,%r14 >>>>> 000000000e0acf66: 47000700 bc >>>>> 0,1792 >>>>> [ 21.408883] Call Trace: >>>>> >>>>> After the patch: >>>>> [ 21.408784] Krnl GPRS: 000002aa3780c000 0000000000238c00 >>>>> 0000000015800000 0000000000001000 >>>>> [ 21.408787] 0000000008e30000 00000000b0001000 >>>>> 0000000000000000 0000000000000a55 >>>>> [ 21.408790] 0000000004c52300 000002aa3780c000 >>>>> 00000000084281d0 0000038000bfbd28 >>>>> [ 21.408794] 00000000075e9500 0000000004c52300 >>>>> 0000038000bfbbf0 0000038000bfbb90 >>>>> [ 21.408860] >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Krnl Code: 000000000e0acf48: c05fb0001000 llilf >>>>> %r5,2952794112 >>>>> [ 21.408883] Call Trace: >>>>> >>>>> I think your approach of storing printable characters in the buffer with >>>>> the intention to modify it >>>>> afterwards (see [1] below) instead of writing it character wise does not >>>>> work when the input data >>>>> contains several lines. Those '\n' are written one by one, what leads to >>>>> the result shown above. >>>>> You should probably buffer and 'demangle' each line separately. >>>>> >>>> >>>> Looks like different issues. Can you share your vmcore and vmlinux with >>>> me? I did not reproduce it. >>> >>> >>>> >>>> Thanks >>>> Lianbo >>>> >>>>> >>>>> >>>> >>> > -- Crash-utility mailing list -- [email protected] To unsubscribe send an email to [email protected] https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/ Contribution Guidelines: https://github.com/crash-utility/crash/wiki
