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?
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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
cd /sys/bus/coresight/devices/tmc_etrXX/
Change to special mode called, read_prevboot.
#echo 1 > read_prevboot
Dump trace buffer data to a file,
#dd if=/dev/tmc_etrXX of=~/cstrace.bin
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?
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?
b. Reserved memory region given by firmware for trace buffer and metadata has to be in persistent RAM. Note: This is a requirement for watchdog reset case but optional in kernel panic case.
Watchdog reset can be supported only on platforms that meet the above two requirements.
Testing so far:
Watchdog reset has been tested on Marvell SOCs using the above approach on 5.x kernel version with sysfs method.
Linu Cherian (5): dt-bindings: arm: coresight-tmc: Add "memory-region" property ccoresight: tmc-etr: Add support to use reserved trace memory coresight: core: Add provision for panic callbacks coresight: tmc: Add support for panic sync handling coresight: tmc: Add support for reading tracedata from previous boot
.../bindings/arm/arm,coresight-tmc.yaml | 9 ++ drivers/hwtracing/coresight/coresight-core.c | 31 +++++ drivers/hwtracing/coresight/coresight-priv.h | 1 + .../hwtracing/coresight/coresight-tmc-core.c | 112 ++++++++++++++++++ .../hwtracing/coresight/coresight-tmc-etf.c | 69 +++++++++++ .../hwtracing/coresight/coresight-tmc-etr.c | 98 ++++++++++++++- drivers/hwtracing/coresight/coresight-tmc.h | 32 +++++ include/linux/coresight.h | 11 ++ 8 files changed, 362 insertions(+), 1 deletion(-)