Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230327115642.1610-1-cuiyunhui@bytedance.com> <d7111158-7e17-4c88-a8c1-a568db5891fa@spud>
In-Reply-To: <d7111158-7e17-4c88-a8c1-a568db5891fa@spud>
From:   =?UTF-8?B?6L+Q6L6J5bSU?= <cuiyunhui@bytedance.com>
Date:   Wed, 29 Mar 2023 11:52:21 +0800
Message-ID: <CAEEQ3wkKr9NhKwo0O3D=pfi80j7-cup3VgaWuk8vdk87=ryy6g@mail.gmail.com>
Subject: Re: [External] Re: [PATCH] riscv/fault: Dump user opcode bytes on
 fatal faults
To:     Conor Dooley <conor@kernel.org>
Cc:     paul.walmsley@sifive.com, palmer@dabbelt.com,
        aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Conor,

On Wed, Mar 29, 2023 at 1:03=E2=80=AFAM Conor Dooley <conor@kernel.org> wro=
te:

> 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 0x000000000005e0=
28 in bb[10000+5fe000]
> > [    0.932292] CPU: 0 PID: 1 Comm: init Not tainted 5.14.0-rc4-00048-g4=
a843c9043e8-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 : 000000=
0000000000
> > [    0.936495]  s5 : 0000000000000000 s6 : 0000000000000000 s7 : 000000=
0000000000
> > [    0.936947]  s8 : 0000000000000000 s9 : 0000000000000000 s10: 000000=
0000000000
> > [    0.937487]  s11: 0000000000d14980 t3 : 0000000000000000 t4 : 000000=
0000000000
> > [    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.