On 14/06/2023 15:06, Linu Cherian wrote:

Hi James,

...

-----Original Message----- From: James Clark james.clark@arm.com Sent: Tuesday, June 13, 2023 3:08 PM To: Linu Cherian lcherian@marvell.com; mathieu.poirier@linaro.org; suzuki.poulose@arm.com; mike.leach@linaro.org Cc: coresight@lists.linaro.org; Anil Kumar Reddy H areddy3@marvell.com; George Cherian gcherian@marvell.com Subject: [EXT] Re: [RFC PATCH 0/5]Extending Coresight for Kernel panic and watchdog reset

External Email

---

On 02/05/2023 07:50, Linu Cherian wrote:

...

Hi,

Sharing here the design notes and work in progress patches to get some early feedback on the implementation approach.

Introduction

This RFC is about extending Linux coresight driver support to address kernel panic and watchdog reset scenarios. This would help coresight users to debug kernel panic and watchdog reset with the help of coresight trace data.

For simplicity, watchdog and kernel panic are addressed in separate sections.

Coresight trace capture: Kernel panic

From the coresight driver point of view, addressing the kernel panic situation has four main requirements.

a. Support for allocation of trace buffer pages from reserved memory area. Platform can advertise this using a new device tree property added to relevant coresight nodes.

b. Support for stopping coresight blocks at the time of panic

c. Saving required metadata in the specified format

d. Support for reading trace data captured at the time of panic

Allocation of trace buffer pages from reserved RAM

A new optional device tree property "memory-region" will be added to
the ETR/ETF device nodes, that would give the base address and size of
trace buffer.

Static allocation of trace buffers would ensure that both IOMMU
enabled and disabled cases are handled. Also, platforms that support
persistent RAM will allow users to read trace data in the subsequent
boot without booting the crashdump kernel.

Note:
For ETR sink devices, this reserved region will be used for both trace
capture and trace data retrieval.
For ETF sink devices, internal SRAM would be used for trace capture,
and they would be synced to reserved region for retrieval.

Disabling coresight blocks at the time of panic
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In order to avoid the situation of losing relevant trace data after a
kernel panic, it would be desirable to stop the coresight blocks at
the time of panic.

This can be achieved by configuring the comparator, CTI and sink
devices as below,

Comparator(triggers on kernel panic) --->External out --->CTI --
   							|
   	 ETR/ETF stop <------External In <--------------

Note: No supporting patches are shared for this, since we are planning
to make use of the System configuration manager to achieve the
required configuration. This is a work in progress.

Hi Linu,

Do you have anything to share for this part yet? I'd like to test out the patches with this mode. Or do you just have the watchdog mode working?

Thanks for taking a look at this. Currently we do have the kernel panic case working as well but for a 5.x series.

For stopping Coresight trace at the time of panic involves mainly three changes.

1. ETM resource configuration to generate trigger on "panic"
2. CTI configuration to send the trigger to all ETF/ETR devices (FlushIn Trigger)
3. Configure ETF/ETR devices to flush and stop trace capture on FlushIn Trigger

The initial plan was to get #1 and #2 achieved using the Coresight System configuration manager and #3 would be a kernel change anyways. Since configuration manager support for CTI was work in progress, currently ETM configuration is achieved through a kernel driver change and CTI configuration is done using user space scripts.

Just started working on rebasing these working patches to upstream kernel. Once ready I will send the complete set as V2.

...

...

Saving metadata at the time of kernel panic

Coresight metadata involves all additional data that are required for
a successful trace decode in addition to the trace data. This involves
ETR/ETF, ETE register snapshot etc.

A new optional device property "memory-region" will be added to the
ETR/ETF/ETE device nodes for this.

Reading trace data captured at the time of panic

Trace data captured at the time of panic, can be read from rebooted kernel or from crashdump kernel using the below mentioned interface.

Steps for reading trace data captured in previous boot ++++++++++++++++++++++++++++++++++++++++++++++++++++++

1. cd /sys/bus/coresight/devices/tmc_etrXX/

2. Change to special mode called, read_prevboot.

   #echo 1 > read_prevboot

3. Dump trace buffer data to a file,

   #dd if=/dev/tmc_etrXX of=~/cstrace.bin

4. Reset back to normal mode

   #echo 0 > read_prevboot

I didn't see a step mentioned about how to not overwrite the old data when booting again. Presumably if you want it recording from as early as possible you also need some flag to indicate whether the buffer contains a crash recording or not. I'm also not sure how this flag could be initialised?

Yeah, currently this scenario is not handled. Will look into this.

...

...

General flow of trace capture and decode incase of kernel panic

~~~~~
>
> 1. Enable source and sink on all the cores using the sysfs interface.
>    ETR sink will have trace buffers allocated from reserved memory.
>
> 2. Run relevant tests.
>
> 3. On a kernel panic, all coresight blocks are disabled, necessary
>    metadata is synced by kernel panic handler.
>
>    System would eventually reboot or boot a crashdump kernel.
>
[...]
>
> a. Saving coresight metadata need to be taken care by the
>    SCP(system control processor) firmware in the specified format,
>    instead of kernel.
>

Is it not possible to save the metadata at the beginning? That way it would
work more easily with both panic and watchdog modes. Or is there
something that can't be known ahead of time?

I can't really think of anything that couldn't be known ahead of time.
Unless it's something like the last write pointer?

Yeah, its mainly the write pointer and status register which forces us to take snapshot after the panic/watchdog has triggered.

If you are ok with timestamps being enabled then I wonder if the write pointer is redundant? You can just decode up until there is some kind of error or the timestamp goes backwards and then assume that is the last written point?

Also I've been looking at linux/Documentation/powerpc/firmware-assisted-dump.rst to see if there is anything in there that can be re-used. I don't know if you looked at that much? It seems like there is some precedent for involving the firmware, but if it can be avoided maybe that is simpler and easier to support. If not then maybe some things like the command line arguments can be re-used. Although I understand coredumps are a fairly different concept to trace so maybe we do need to come up with something completely new like the dtb changes you have.