[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aRIo2MUol09Onu9B@p14s>
Date: Mon, 10 Nov 2025 11:03:04 -0700
From: Mathieu Poirier <mathieu.poirier@...aro.org>
To: Peng Fan <peng.fan@....nxp.com>
Cc: Tanmay Shah <tanmay.shah@....com>, andersson@...nel.org,
linux-remoteproc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] remoteproc: xlnx: remote crash recovery
On Thu, Oct 30, 2025 at 12:21:24PM +0800, Peng Fan wrote:
> Hi Tanmay,
>
> On Wed, Oct 29, 2025 at 06:51:51PM -0500, Tanmay Shah wrote:
> ...
> >> >
> >>
> >> Hi Peng,
> >>
> >> I don't understand why it should fail. The patch simply implements
> >> rproc_detach() -> rproc_attach() sequence.
> >>
> >
> >Hi Peng,
> >
> >Thanks for testing the patch. I appreciate your quick response. I think
> >rproc_boot() should be used instead of rproc_attach(). That should probably
> >solve the issue you are facing. I will send v2 with this change for you to
> >try.
> >
> >Thanks,
> >Tanmay
> >
> >> In your case, when you do detach -> attach via sysfs that sequence works?
> >> If that works, then crash recovery should work as well.
>
> sysfs does not have attach option, only start/stop/detach are there.
>
> >>
> >> Could you give steps how do you generate the crash?
>
> I have not look into the details on why it fails at my side for the 2nd time.
>
> On my board, the M4 core use watchdog to reset itself and notify Linux, then
> linux side imx_rproc driver will do
> "rproc_report_crash(priv->rproc, RPROC_WATCHDOG);"
>
> I will give a debug on the failures in a few days.
>
So what is happening here - Peng, do you plan on providing more debugging
information? Tanmay - are you planning on sending a second revision?
> Thanks,
> Peng
>
> >>
> >> Thanks,
> >> Tanmay
> >>
> >> > Thanks,
> >> > Peng
> >>
> >
Powered by blists - more mailing lists