[External] Re: [PATCH] riscv/fault: Dump user opcode bytes on fatal faults

运辉崔 cuiyunhui at bytedance.com
Tue Mar 28 20:52:21 PDT 2023


Hi Conor,

On Wed, Mar 29, 2023 at 1:03 AM Conor Dooley <conor at kernel.org> wrote:

> riscv/fault: Dump user opcode bytes on fatal faults
>
> I think you can drop the /fault, we don't usually use prefixes that like
> for RISC-V.
>
ok, i'll update it on v2


> > In this way, we found the problem: in the system bringup , it is
> > precisely that we have not enabled the floating point function.
>
> What do you mean by that "have not enabled the floating point function"?

The related cpu feature(COMPAT_HWCAP_ISA_F) is not enabled in the
riscv_fill_hwcap function interface.


> > So when an exception occurs, it is necessary to dump the instruction
> > that caused the exception, like x86/fault (ba54d856a9d8).
>
> That's not the usual format for referring to commits, checkpatch should
> complain about that.

ok, i'll update it on v2.

> >
> > Logs:
> > [    0.822481] Run /init as init process
> > [    0.837569] init[1]: unhandled signal 4 code 0x1 at 0x000000000005e028 in bb[10000+5fe000]
> > [    0.932292] CPU: 0 PID: 1 Comm: init Not tainted 5.14.0-rc4-00048-g4a843c9043e8-dirty #138
>
> 5.14-rc4?, oof! Need to get yourself onto a released, LTS kernel I
> think!

Just a print,v6.3-rc1 also has this problem.

>
> Anyway, this patch doesn't apply to either riscv/for-next, riscv/fixes
> or v6.3-rc1. What is the appropriate base to apply this patch?

ok, i'll update it on v2.


> > [    0.936073]  s2 : 0000000000000000 s3 : 0000000000000000 s4 : 0000000000000000
> > [    0.936495]  s5 : 0000000000000000 s6 : 0000000000000000 s7 : 0000000000000000
> > [    0.936947]  s8 : 0000000000000000 s9 : 0000000000000000 s10: 0000000000000000
> > [    0.937487]  s11: 0000000000d14980 t3 : 0000000000000000 t4 : 0000000000000000
> > [    0.937954]  t5 : 0000000000000000 t6 : 0000000000000000
> > [    0.938510] status: 0000000200000020 badaddr: 00000000f0028053 cause: 0000000000000002
>
> I have no idea what the significance of this particular backtrace is,
> could you elaborate on what this is demonstrating? (and drop the leading
> [###] too as it doesn't exactly add anything!

The current call trace does not show the instruction that caused the
exception. ok, I'll remove it on v2.



More information about the linux-riscv mailing list