Messages in this thread | | | Date | Wed, 29 Mar 2023 07:24:45 +0100 | From | Conor Dooley <> | Subject | Re: [External] Re: [PATCH] riscv/fault: Dump user opcode bytes on fatal faults |
| |
Hey 运辉崔,
On Wed, Mar 29, 2023 at 11:52:21AM +0800, 运辉崔 wrote: > On Wed, Mar 29, 2023 at 1:03 AM Conor Dooley <conor@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.
Right, I'm trying to figure out of this is another bug in the kernel - if you don't have "fd" in riscv,isa in your devicetree then, even if CONFIG_FPU is set, none of the FPU code is meant to run, right?
> > > 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.
Right, but that's a pretty old kernel to be using! Seeing 5.14 and the patch not applying made me wonder if the patch was generated against an old kernel.
> > 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.
What would be nice to have is what the new show_opcodes() function will look like ;)
Thanks, Conor. [unhandled content-type:application/pgp-signature] | |