Hi James,
-----Original Message----- From: James Clark james.clark@arm.com Sent: Wednesday, June 14, 2023 8:34 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 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.
- ETM resource configuration to generate trigger on "panic"
- 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 panicTrace 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?
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?
By the way, we cannot do away with saving internal SRAM of ETB to DDR after panic or watchdog since they are not preserved across reset.
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.
Agree with your point of avoiding firmware dependency at any cost. Earlier we have experimented using the ELF core dump option to pass info from primary kernel to secondary kernel, but that doesn’t work for the watchdog reset case and it involves additional user space crash tool extensions as well.
Using firmware allocated memory region for trace data/metadata for each sink devices allows both kernel panic and watchdog case to work seamlessly.
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.