On 2/27/2023 4:43 AM, Souradeep Chowdhury wrote:
On 2/22/2023 5:43 PM, Leo Yan wrote:
Hi Souradeep,
On Wed, Feb 22, 2023 at 04:46:07PM +0530, Souradeep Chowdhury wrote:
On 2/22/2023 7:13 AM, Leo Yan wrote:
On Wed, Feb 15, 2023 at 04:05:36PM +0100, Arnd Bergmann wrote:
[...]
If the possible use is purely for saving some state across
a reboot, as opposed to other events, I wonder if there is
a good way to integrate it into the fs/pstore/ code, which
already has a way to multiplex various kinds of input (log
buffer, ftrace call chain, userspace strings, ...) into
various kinds of persistent buffers (sram, blockdev, mtd,
efivars, ...) with the purpose of helping analyze the
state after a reboot.
Good point!
I understand pstore/ramoops is somehow like a sink which routes the
tracing data (software tracing data but not hadware tracing data) to
persistent memory. This is why we also can route these software
tracing data to STM (hardware sink!).
Seems to me, Arnd suggests to connect two sinks between DCC and
pstore (to persistent memory). But I cannot give an example code in
kernel for doing this way, sorry if I miss something.
Essentially, a good user case is to keep a persistent memory for the
tracing data, then after rebooting cycle we can retrieve the tracing
data via user space interface (like sysfs node).
Hi Leo/Arnd,
Just wanted to let you know that the justification of not using
PStore was
already given in the version 1 of this patch series as below
https://lore.kernel.org/linux-arm-msm/ab30490c016f906fd9bc5d789198530b@xxxxxxxxxxxxxx/#r
PStore/Ramoops only persists across warm-reboots which is present for
chrome
devices but not for android ones.
Thanks for the info. Just remind a subtle difference of reboots.
Besides warm reboot, kernel can reboot system after panic (see kernel
command line option `panic`) and watchdog can reboot the system as well.
Even though Android doesn't support warm reboot, system still can reboot
on panic or by watchdog (in particular after bus lockup), pstore/ramoops
also can support these cases.
So for the SoCs that doesn't support warm reboots, the DDR memory is non
persistent across panics or watchdog bites in which case the
PStore/Ramoops cannot be of use.
Also the dcc_sram contents can
also be collected by going for a software trigger after loading the
kernel
and the dcc_sram is parsed to get the register values with the
opensource parser as below
https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/tools/tree/dcc_parser
To be clear, current driver is fine for me (TBH, I didn't spend much
time to read it but it's very neat after quickly went through it), I
just share some info in case it's helpful for the discussion.
What is the conclusion here? Can we pick up the DCC now if we rebase to
the latest tree? It seems so far response here is that driver is fine
as-is and it can be included without any changes. I want this driver
discussion to be concluded since we are trying to submit it for more
than 23 months (as Bjorn counted :) ).
---Trilok Soni
