| Message ID | 20230904050548.28047-1-lcherian@marvell.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Coresight for Kernel panic and watchdog reset | expand |
On 04/09/2023 06:05, Linu Cherian wrote: > This RFC v3 patch series is rebased on v6.5-rc7 and is dependent > on the below two patches. [...] > > 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 Hi Linu, I left this comment on V2, but I tested it again and get the same result. Instead of linking it I'll just re-paste it here: I made a reserved region, but when I run this command I get "Unable to handle kernel paging request at virtual address 001f1921ed10ffae". Is there an extra step involved if there was no trace captured from a previous panic? I thought I'd just be able to read out uninitialised data. Or is it the uninitialised metadata that's causing this issue? Also that's without KASAN or lockdep turned on. If I have a kernel with either of those things I get a different warning for each one. I expect the lockdep one would happen even in the working scenario though? > > 4. Reset back to normal mode > > #echo 0 > read_prevboot >
Hi James, > -----Original Message----- > From: James Clark <james.clark@arm.com> > Sent: Friday, September 15, 2023 7:20 PM > To: Linu Cherian <lcherian@marvell.com>; suzuki.poulose@arm.com; > mike.leach@linaro.org; leo.yan@linaro.org > Cc: linux-arm-kernel@lists.infradead.org; coresight@lists.linaro.org; linux- > kernel@vger.kernel.org; robh+dt@kernel.org; > krzysztof.kozlowski+dt@linaro.org; conor+dt@kernel.org; > devicetree@vger.kernel.org; Sunil Kovvuri Goutham > <sgoutham@marvell.com>; George Cherian <gcherian@marvell.com> > Subject: [EXT] Re: [RFC PATCH v3 0/8] Coresight for Kernel panic and > watchdog reset > > External Email > > ---------------------------------------------------------------------- > > > On 04/09/2023 06:05, Linu Cherian wrote: > > This RFC v3 patch series is rebased on v6.5-rc7 and is dependent on > > the below two patches. > [...] > > > > 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 > > Hi Linu, > > I left this comment on V2, but I tested it again and get the same result. > Instead of linking it I'll just re-paste it here: > > I made a reserved region, but when I run this command I get "Unable to > handle kernel paging request at virtual address 001f1921ed10ffae". > > Is there an extra step involved if there was no trace captured from a previous > panic? I thought I'd just be able to read out uninitialised data. Or is it the > uninitialised metadata that's causing this issue? > > Also that's without KASAN or lockdep turned on. If I have a kernel with either > of those things I get a different warning for each one. I expect the lockdep > one would happen even in the working scenario though? Somehow I missed this comment on V2. I retried the above steps on my board and I do not see issues either with KASAN OR lockdep enabled configs. Please see logs below. a. Lockdep enabled config ~# cd /sys/bus/coresight/devices/tmc_etr0 tmc_etr0# echo 1 > read_prevboot tmc_etr0# dd if=/dev/tmc_etr0 of=~/cstrace.bin 12324+1 records in 12324+1 records out 6310032 bytes (6.3 MB, 6.0 MiB) copied, 0.122883 s, 51.3 MB/s # zcat /proc/config.gz | grep LOCKDEP CONFIG_LOCKDEP_SUPPORT=y CONFIG_LOCKDEP=y CONFIG_LOCKDEP_BITS=15 CONFIG_LOCKDEP_CHAINS_BITS=16 CONFIG_LOCKDEP_STACK_TRACE_BITS=19 CONFIG_LOCKDEP_STACK_TRACE_HASH_BITS=14 CONFIG_LOCKDEP_CIRCULAR_QUEUE_BITS=12 # CONFIG_DEBUG_LOCKDEP is not set b. KASAN enabled config # cd /sys/bus/coresight/devices/tmc_etr0/ tmc_etr0# ls buf_mode_preferred connections power trigger_cntr buf_modes_available enable_sink read_prevboot uevent buffer_size mgmt subsystem waiting_for_supplier tmc_etr0# echo 1 > read_prevboot tmc_etr0# dd if=/dev/tmc_etr0 of=~/cstrace.bin 12324+1 records in 12324+1 records out 6310032 bytes (6.3 MB, 6.0 MiB) copied, 0.0940671 s, 67.1 MB/s ~# zcat /proc/config.gz | grep -i kasan CONFIG_KASAN_SHADOW_OFFSET=0xdfff800000000000 CONFIG_HAVE_ARCH_KASAN=y CONFIG_HAVE_ARCH_KASAN_SW_TAGS=y CONFIG_HAVE_ARCH_KASAN_HW_TAGS=y CONFIG_HAVE_ARCH_KASAN_VMALLOC=y CONFIG_CC_HAS_KASAN_GENERIC=y CONFIG_CC_HAS_KASAN_SW_TAGS=y CONFIG_KASAN=y CONFIG_KASAN_GENERIC=y # CONFIG_KASAN_SW_TAGS is not set # CONFIG_KASAN_HW_TAGS is not set CONFIG_KASAN_OUTLINE=y # CONFIG_KASAN_INLINE is not set CONFIG_KASAN_STACK=y CONFIG_KASAN_VMALLOC=y # CONFIG_KASAN_MODULE_TEST is not set But then I am able to trigger kernel crash with bad metadata(corrupted rwp and rrp) with below stack trace. [ 107.442991] __arch_copy_to_user+0x180/0x240 [ 107.447254] vfs_read+0xc8/0x2a8 [ 107.450476] ksys_read+0x74/0x110 [ 107.453783] __arm64_sys_read+0x24/0x38 [ 107.457611] invoke_syscall.constprop.0+0x58/0xf8 [ 107.462309] do_el0_svc+0x6c/0x158 [ 107.465704] el0_svc+0x54/0x1c0 [ 107.468839] el0t_64_sync_handler+0x100/0x130 [ 107.473188] el0t_64_sync+0x190/0x198 [ 107.476843] Code: d503201f d503201f d503201f d503201f (a8c12027) Does your stack trace looks similar ? Then its very likely due to bad metadata. If not, kindly please share yours. For example, if we have bad values for rwp and rrp, offset can get messed up resulting in above crash. Will add more validation checks while setting up the prevboot buffer, so as to avoid processing with bogus metadata values in the next patch version. Thanks James for trying this out. > > > > > 4. Reset back to normal mode > > > > #echo 0 > read_prevboot > >
On 19/09/2023 12:39, Linu Cherian wrote: > Hi James, > >> -----Original Message----- >> From: James Clark <james.clark@arm.com> >> Sent: Friday, September 15, 2023 7:20 PM >> To: Linu Cherian <lcherian@marvell.com>; suzuki.poulose@arm.com; >> mike.leach@linaro.org; leo.yan@linaro.org >> Cc: linux-arm-kernel@lists.infradead.org; coresight@lists.linaro.org; linux- >> kernel@vger.kernel.org; robh+dt@kernel.org; >> krzysztof.kozlowski+dt@linaro.org; conor+dt@kernel.org; >> devicetree@vger.kernel.org; Sunil Kovvuri Goutham >> <sgoutham@marvell.com>; George Cherian <gcherian@marvell.com> >> Subject: [EXT] Re: [RFC PATCH v3 0/8] Coresight for Kernel panic and >> watchdog reset >> >> External Email >> >> ---------------------------------------------------------------------- >> >> >> On 04/09/2023 06:05, Linu Cherian wrote: >>> This RFC v3 patch series is rebased on v6.5-rc7 and is dependent on >>> the below two patches. >> [...] >>> >>> 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 >> >> Hi Linu, >> >> I left this comment on V2, but I tested it again and get the same result. >> Instead of linking it I'll just re-paste it here: >> >> I made a reserved region, but when I run this command I get "Unable to >> handle kernel paging request at virtual address 001f1921ed10ffae". >> >> Is there an extra step involved if there was no trace captured from a previous >> panic? I thought I'd just be able to read out uninitialised data. Or is it the >> uninitialised metadata that's causing this issue? >> >> Also that's without KASAN or lockdep turned on. If I have a kernel with either >> of those things I get a different warning for each one. I expect the lockdep >> one would happen even in the working scenario though? > > Somehow I missed this comment on V2. > > I retried the above steps on my board and I do not see issues either with KASAN OR lockdep enabled configs. > Please see logs below. > > a. Lockdep enabled config > ~# cd /sys/bus/coresight/devices/tmc_etr0 > tmc_etr0# echo 1 > read_prevboot > tmc_etr0# dd if=/dev/tmc_etr0 of=~/cstrace.bin > 12324+1 records in > 12324+1 records out > 6310032 bytes (6.3 MB, 6.0 MiB) copied, 0.122883 s, 51.3 MB/s > > # zcat /proc/config.gz | grep LOCKDEP > CONFIG_LOCKDEP_SUPPORT=y > CONFIG_LOCKDEP=y > CONFIG_LOCKDEP_BITS=15 > CONFIG_LOCKDEP_CHAINS_BITS=16 > CONFIG_LOCKDEP_STACK_TRACE_BITS=19 > CONFIG_LOCKDEP_STACK_TRACE_HASH_BITS=14 > CONFIG_LOCKDEP_CIRCULAR_QUEUE_BITS=12 > # CONFIG_DEBUG_LOCKDEP is not set > > b. KASAN enabled config > # cd /sys/bus/coresight/devices/tmc_etr0/ > tmc_etr0# ls > buf_mode_preferred connections power trigger_cntr > buf_modes_available enable_sink read_prevboot uevent > buffer_size mgmt subsystem waiting_for_supplier > tmc_etr0# echo 1 > read_prevboot > tmc_etr0# dd if=/dev/tmc_etr0 of=~/cstrace.bin > 12324+1 records in > 12324+1 records out > 6310032 bytes (6.3 MB, 6.0 MiB) copied, 0.0940671 s, 67.1 MB/s > > ~# zcat /proc/config.gz | grep -i kasan > CONFIG_KASAN_SHADOW_OFFSET=0xdfff800000000000 > CONFIG_HAVE_ARCH_KASAN=y > CONFIG_HAVE_ARCH_KASAN_SW_TAGS=y > CONFIG_HAVE_ARCH_KASAN_HW_TAGS=y > CONFIG_HAVE_ARCH_KASAN_VMALLOC=y > CONFIG_CC_HAS_KASAN_GENERIC=y > CONFIG_CC_HAS_KASAN_SW_TAGS=y > CONFIG_KASAN=y > CONFIG_KASAN_GENERIC=y > # CONFIG_KASAN_SW_TAGS is not set > # CONFIG_KASAN_HW_TAGS is not set > CONFIG_KASAN_OUTLINE=y > # CONFIG_KASAN_INLINE is not set > CONFIG_KASAN_STACK=y > CONFIG_KASAN_VMALLOC=y > # CONFIG_KASAN_MODULE_TEST is not set > > > But then I am able to trigger kernel crash with bad metadata(corrupted rwp and rrp) with below stack trace. > > [ 107.442991] __arch_copy_to_user+0x180/0x240 > [ 107.447254] vfs_read+0xc8/0x2a8 > [ 107.450476] ksys_read+0x74/0x110 > [ 107.453783] __arm64_sys_read+0x24/0x38 > [ 107.457611] invoke_syscall.constprop.0+0x58/0xf8 > [ 107.462309] do_el0_svc+0x6c/0x158 > [ 107.465704] el0_svc+0x54/0x1c0 > [ 107.468839] el0t_64_sync_handler+0x100/0x130 > [ 107.473188] el0t_64_sync+0x190/0x198 > [ 107.476843] Code: d503201f d503201f d503201f d503201f (a8c12027) > > Does your stack trace looks similar ? Then its very likely due to bad metadata. > If not, kindly please share yours. > > For example, if we have bad values for rwp and rrp, offset can get messed up resulting in above crash. > Will add more validation checks while setting up the prevboot buffer, so as to avoid processing with bogus metadata values > in the next patch version. > > Thanks James for trying this out. > > I think it must be bad metadata because I didn't try it with a previous crash saved yet. I suppose we do need some kind of validation then if it's possible for bad metadata to cause a crash. I will try after filling in the metadata and see if that was the issue. > >> >>> >>> 4. Reset back to normal mode >>> >>> #echo 0 > read_prevboot >>>
Hi James, > -----Original Message----- > From: James Clark <james.clark@arm.com> > Sent: Tuesday, September 19, 2023 6:41 PM > To: Linu Cherian <lcherian@marvell.com>; suzuki.poulose@arm.com; > mike.leach@linaro.org; leo.yan@linaro.org > Cc: linux-arm-kernel@lists.infradead.org; coresight@lists.linaro.org; linux- > kernel@vger.kernel.org; robh+dt@kernel.org; > krzysztof.kozlowski+dt@linaro.org; conor+dt@kernel.org; > devicetree@vger.kernel.org; Sunil Kovvuri Goutham > <sgoutham@marvell.com>; George Cherian <gcherian@marvell.com> > Subject: Re: [EXT] Re: [RFC PATCH v3 0/8] Coresight for Kernel panic and > watchdog reset > > > > On 19/09/2023 12:39, Linu Cherian wrote: > > Hi James, > > > >> -----Original Message----- > >> From: James Clark <james.clark@arm.com> > >> Sent: Friday, September 15, 2023 7:20 PM > >> To: Linu Cherian <lcherian@marvell.com>; suzuki.poulose@arm.com; > >> mike.leach@linaro.org; leo.yan@linaro.org > >> Cc: linux-arm-kernel@lists.infradead.org; coresight@lists.linaro.org; > >> linux- kernel@vger.kernel.org; robh+dt@kernel.org; > >> krzysztof.kozlowski+dt@linaro.org; conor+dt@kernel.org; > >> devicetree@vger.kernel.org; Sunil Kovvuri Goutham > >> <sgoutham@marvell.com>; George Cherian <gcherian@marvell.com> > >> Subject: [EXT] Re: [RFC PATCH v3 0/8] Coresight for Kernel panic and > >> watchdog reset > >> > >> External Email > >> > >> --------------------------------------------------------------------- > >> - > >> > >> > >> On 04/09/2023 06:05, Linu Cherian wrote: > >>> This RFC v3 patch series is rebased on v6.5-rc7 and is dependent on > >>> the below two patches. > >> [...] > >>> > >>> 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 > >> > >> Hi Linu, > >> > >> I left this comment on V2, but I tested it again and get the same result. > >> Instead of linking it I'll just re-paste it here: > >> > >> I made a reserved region, but when I run this command I get "Unable > >> to handle kernel paging request at virtual address 001f1921ed10ffae". > >> > >> Is there an extra step involved if there was no trace captured from a > >> previous panic? I thought I'd just be able to read out uninitialised > >> data. Or is it the uninitialised metadata that's causing this issue? > >> > >> Also that's without KASAN or lockdep turned on. If I have a kernel > >> with either of those things I get a different warning for each one. I > >> expect the lockdep one would happen even in the working scenario > though? > > > > Somehow I missed this comment on V2. > > > > I retried the above steps on my board and I do not see issues either with > KASAN OR lockdep enabled configs. > > Please see logs below. > > > > a. Lockdep enabled config > > ~# cd /sys/bus/coresight/devices/tmc_etr0 > > tmc_etr0# echo 1 > read_prevboot > > tmc_etr0# dd if=/dev/tmc_etr0 of=~/cstrace.bin > > 12324+1 records in > > 12324+1 records out > > 6310032 bytes (6.3 MB, 6.0 MiB) copied, 0.122883 s, 51.3 MB/s > > > > # zcat /proc/config.gz | grep LOCKDEP > > CONFIG_LOCKDEP_SUPPORT=y > > CONFIG_LOCKDEP=y > > CONFIG_LOCKDEP_BITS=15 > > CONFIG_LOCKDEP_CHAINS_BITS=16 > > CONFIG_LOCKDEP_STACK_TRACE_BITS=19 > > CONFIG_LOCKDEP_STACK_TRACE_HASH_BITS=14 > > CONFIG_LOCKDEP_CIRCULAR_QUEUE_BITS=12 > > # CONFIG_DEBUG_LOCKDEP is not set > > > > b. KASAN enabled config > > # cd /sys/bus/coresight/devices/tmc_etr0/ > > tmc_etr0# ls > > buf_mode_preferred connections power trigger_cntr > > buf_modes_available enable_sink read_prevboot uevent > > buffer_size mgmt subsystem waiting_for_supplier > > tmc_etr0# echo 1 > read_prevboot > > tmc_etr0# dd if=/dev/tmc_etr0 of=~/cstrace.bin > > 12324+1 records in > > 12324+1 records out > > 6310032 bytes (6.3 MB, 6.0 MiB) copied, 0.0940671 s, 67.1 MB/s > > > > ~# zcat /proc/config.gz | grep -i kasan > > CONFIG_KASAN_SHADOW_OFFSET=0xdfff800000000000 > > CONFIG_HAVE_ARCH_KASAN=y > > CONFIG_HAVE_ARCH_KASAN_SW_TAGS=y > > CONFIG_HAVE_ARCH_KASAN_HW_TAGS=y > > CONFIG_HAVE_ARCH_KASAN_VMALLOC=y > > CONFIG_CC_HAS_KASAN_GENERIC=y > > CONFIG_CC_HAS_KASAN_SW_TAGS=y > > CONFIG_KASAN=y > > CONFIG_KASAN_GENERIC=y > > # CONFIG_KASAN_SW_TAGS is not set > > # CONFIG_KASAN_HW_TAGS is not set > > CONFIG_KASAN_OUTLINE=y > > # CONFIG_KASAN_INLINE is not set > > CONFIG_KASAN_STACK=y > > CONFIG_KASAN_VMALLOC=y > > # CONFIG_KASAN_MODULE_TEST is not set > > > > > > But then I am able to trigger kernel crash with bad metadata(corrupted rwp > and rrp) with below stack trace. > > > > [ 107.442991] __arch_copy_to_user+0x180/0x240 [ 107.447254] > > vfs_read+0xc8/0x2a8 [ 107.450476] ksys_read+0x74/0x110 [ > > 107.453783] __arm64_sys_read+0x24/0x38 [ 107.457611] > > invoke_syscall.constprop.0+0x58/0xf8 > > [ 107.462309] do_el0_svc+0x6c/0x158 > > [ 107.465704] el0_svc+0x54/0x1c0 > > [ 107.468839] el0t_64_sync_handler+0x100/0x130 [ 107.473188] > > el0t_64_sync+0x190/0x198 [ 107.476843] Code: d503201f d503201f > > d503201f d503201f (a8c12027) > > > > Does your stack trace looks similar ? Then its very likely due to bad > metadata. > > If not, kindly please share yours. > > > > For example, if we have bad values for rwp and rrp, offset can get messed > up resulting in above crash. > > Will add more validation checks while setting up the prevboot buffer, > > so as to avoid processing with bogus metadata values in the next patch > version. > > > > Thanks James for trying this out. > > > > > > I think it must be bad metadata because I didn't try it with a previous crash > saved yet. I suppose we do need some kind of validation then if it's possible > for bad metadata to cause a crash. > > I will try after filling in the metadata and see if that was the issue. Found a regression in this series. Below is the fix. @@ -1840,7 +1853,7 @@ static int tmc_panic_sync_etr(struct coresight_device *csdev) /* Sync registers from hardware to metadata region */ tmc->size = csdev_access_relaxed_read32(csa, TMC_RSZ); - tmc->sts = csdev_access_relaxed_read32(csa, TMC_RSZ); + tmc->sts = csdev_access_relaxed_read32(csa, TMC_STS); > > > >> > >>> > >>> 4. Reset back to normal mode > >>> > >>> #echo 0 > read_prevboot > >>>
This RFC v3 patch series is rebased on v6.5-rc7 and is dependent on the below two patches. - coresight: tmc: Make etr buffer mode user configurable from sysfs[1] - coresight: Fix run time warnings while reusing ETR buffer[2] Changelog from v2: * ETR reserved buffer mode can be selected only through the new sysfs buffer mode and not by default. This would avoid any conflicts with normal usage. * ETR buffer size in reserved mode is now always fixed to the maximum size of the reserved buffer and not user configurable. This avoids any conflicts with the default buffer size used in other ETR buffer modes. * Introduced new ops called prevboot_ops to factor out common code in tmc_etr_prepare_prevboot() and tmc_etb_prepare_prevboot(). spin_lock/unlock invocations tmc_read_prepare_* are now in a single function. * Added more stringent checks for selecting READ_PREVBOOT mode Other misc changes: * Added more details to DT bindings documentation * Fixed unhandled case error in etm4_disable with CONFIG_WERROR * TMC register saving now uses standard accessor functions * Added panic notifier unregistration * memremap of reserved and metadata buffers are now with _WB attributes * Cover letter title has been shortened. Changelog from v1: * V2 is a complete patchset with kernel panic trace tested on Linux 6.4. Details on testing with relevant console logs has been added for reference. * Two additional patches(patch 6 & 7) has been included to manage stopping of trace at the time of kernel panic. * Few bug fixes. RFC v1 is posted here: https://lists.linaro.org/archives/list/coresight@lists.linaro.org/thread/6FANLYCCSZROLJMERS2MVCKFBBZOMGHJ/ Using Coresight for Kernel panic and Watchdog reset =================================================== 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. 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" is 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. Note: Patches 1 & 2 adds support for this. 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: * Patch 6 provides the necessary ETR configuration. * Patch 7 provides the necessary ETM configuration. 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" is added to the ETR/ETF/ETE device nodes for this. Note: Patches 3 & 4 adds support 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. Note: Patch 5 adds support for this. 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 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, by selecting "resrv" buffer mode from sysfs. 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. 4. For platforms that supports crashdump kernel, raw trace data can be dumped using the coresight sysfs interface from the crashdump kernel itself. Persistent RAM is not a requirement in this case. 5. For platforms that supports persistent RAM, trace data can be dumped using the coresight sysfs interface in the subsequent Linux boot. Crashdump kernel is not a requirement in this case. Persistent RAM ensures that trace data is intact across reboot. Coresight trace capture: Watchdog reset --------------------------------------- The main difference between addressing the watchdog reset and kernel panic case are below, a. Saving coresight metadata need to be taken care by the SCP(system control processor) firmware in the specified format, instead of kernel. 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 Kernel panic on Linux 6.5 --------------------------------- 1. Configure CTI using sysfs interface #./cti_setup.sh #cat cti_setup.sh cd /sys/bus/coresight/devices/ ap_cti_config () { #ETM trig out[0] trigger to Channel 0 echo 0 4 > channels/trigin_attach } etf_cti_config () { #ETF Flush in trigger from Channel 0 echo 0 1 > channels/trigout_attach echo 1 > channels/trig_filter_enable } etr_cti_config () { #ETR Flush in from Channel 0 echo 0 1 > channels/trigout_attach echo 1 > channels/trig_filter_enable } ctidevs=`find . -name "cti*"` for i in $ctidevs do cd $i connection=`find . -name "ete*"` if [ ! -z "$connection" ] then echo "AP CTI config for $i" ap_cti_config fi connection=`find . -name "tmc_etf*"` if [ ! -z "$connection" ] then echo "ETF CTI config for $i" etf_cti_config fi connection=`find . -name "tmc_etr*"` if [ ! -z "$connection" ] then echo "ETR CTI config for $i" etr_cti_config fi cd .. done Note: CTI connections are SOC specific and hence the above script is added just for reference. 2. Start Coresight tracing on cores 1 and 2 using sysfs interface 3. Run some application on core 1 #taskset -c 1 dd if=/dev/urandom of=/dev/null & 4. Invoke kernel panic on core 2 #echo 1 > /proc/sys/kernel/panic #taskset -c 2 echo c > /proc/sysrq-trigger 5. From rebooted kernel, enable previous boot mode #echo 1 > /sys/bus/coresight/devices/tmc_etr0/read_prevboot 6. Read trace data #dd if=/dev/tmc_etr0 of=/trace/cstrace.bin 7. Run opencsd decoder tools/scripts to generate the instruction trace. Core 1 instruction trace dump: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> A etm4_enable_hw: ffff800008ae1dd4 CONTEXT EL2 etm4_enable_hw: ffff800008ae1dd4 I etm4_enable_hw: ffff800008ae1dd4: d503201f nop I etm4_enable_hw: ffff800008ae1dd8: d503201f nop I etm4_enable_hw: ffff800008ae1ddc: d503201f nop I etm4_enable_hw: ffff800008ae1de0: d503201f nop I etm4_enable_hw: ffff800008ae1de4: d503201f nop I etm4_enable_hw: ffff800008ae1de8: d503233f paciasp I etm4_enable_hw: ffff800008ae1dec: a9be7bfd stp x29, x30, [sp, #-32]! I etm4_enable_hw: ffff800008ae1df0: 910003fd mov x29, sp I etm4_enable_hw: ffff800008ae1df4: a90153f3 stp x19, x20, [sp, #16] I etm4_enable_hw: ffff800008ae1df8: 2a0003f4 mov w20, w0 I etm4_enable_hw: ffff800008ae1dfc: 900085b3 adrp x19, ffff800009b95000 <reserved_mem+0xc48> I etm4_enable_hw: ffff800008ae1e00: 910f4273 add x19, x19, #0x3d0 I etm4_enable_hw: ffff800008ae1e04: f8747a60 ldr x0, [x19, x20, lsl #3] E etm4_enable_hw: ffff800008ae1e08: b4000140 cbz x0, ffff800008ae1e30 <etm4_starting_cpu+0x50> I 149.039572921 etm4_enable_hw: ffff800008ae1e30: a94153f3 ldp x19, x20, [sp, #16] I 149.039572921 etm4_enable_hw: ffff800008ae1e34: 52800000 mov w0, #0x0 // #0 I 149.039572921 etm4_enable_hw: ffff800008ae1e38: a8c27bfd ldp x29, x30, [sp], #32 ..snip 149.052324811 chacha_block_generic: ffff800008642d80: 9100a3e0 add x0, I 149.052324811 chacha_block_generic: ffff800008642d84: b86178a2 ldr w2, [x5, x1, lsl #2] I 149.052324811 chacha_block_generic: ffff800008642d88: 8b010803 add x3, x0, x1, lsl #2 I 149.052324811 chacha_block_generic: ffff800008642d8c: b85fc063 ldur w3, [x3, #-4] I 149.052324811 chacha_block_generic: ffff800008642d90: 0b030042 add w2, w2, w3 I 149.052324811 chacha_block_generic: ffff800008642d94: b8217882 str w2, [x4, x1, lsl #2] I 149.052324811 chacha_block_generic: ffff800008642d98: 91000421 add x1, x1, #0x1 I 149.052324811 chacha_block_generic: ffff800008642d9c: f100443f cmp x1, #0x11 Core 2 instruction trace dump(kernel panic triggered core): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A etm4_enable_hw: ffff800008ae1dd4 CONTEXT EL2 etm4_enable_hw: ffff800008ae1dd4 I etm4_enable_hw: ffff800008ae1dd4: d503201f nop I etm4_enable_hw: ffff800008ae1dd8: d503201f nop I etm4_enable_hw: ffff800008ae1ddc: d503201f nop I etm4_enable_hw: ffff800008ae1de0: d503201f nop I etm4_enable_hw: ffff800008ae1de4: d503201f nop I etm4_enable_hw: ffff800008ae1de8: d503233f paciasp I etm4_enable_hw: ffff800008ae1dec: a9be7bfd stp x29, x30, [sp, #-32]! I etm4_enable_hw: ffff800008ae1df0: 910003fd mov x29, sp I etm4_enable_hw: ffff800008ae1df4: a90153f3 stp x19, x20, [sp, #16] I etm4_enable_hw: ffff800008ae1df8: 2a0003f4 mov w20, w0 I etm4_enable_hw: ffff800008ae1dfc: 900085b3 adrp x19, ffff800009b95000 <reserved_mem+0xc48> I etm4_enable_hw: ffff800008ae1e00: 910f4273 add x19, x19, #0x3d0 I etm4_enable_hw: ffff800008ae1e04: f8747a60 ldr x0, [x19, x20, lsl #3] E etm4_enable_hw: ffff800008ae1e08: b4000140 cbz x0, ffff800008ae1e30 <etm4_starting_cpu+0x50> I 149.046243445 etm4_enable_hw: ffff800008ae1e30: a94153f3 ldp x19, x20, [sp, #16] I 149.046243445 etm4_enable_hw: ffff800008ae1e34: 52800000 mov w0, #0x0 // #0 I 149.046243445 etm4_enable_hw: ffff800008ae1e38: a8c27bfd ldp x29, x30, [sp], #32 I 149.046243445 etm4_enable_hw: ffff800008ae1e3c: d50323bf autiasp E 149.046243445 etm4_enable_hw: ffff800008ae1e40: d65f03c0 ret A ete_sysreg_write: ffff800008adfa18 ..snip I 149.05422547 panic: ffff800008096300: a90363f7 stp x23, x24, [sp, #48] I 149.05422547 panic: ffff800008096304: 6b00003f cmp w1, w0 I 149.05422547 panic: ffff800008096308: 3a411804 ccmn w0, #0x1, #0x4, ne // ne = any N 149.05422547 panic: ffff80000809630c: 540001e0 b.eq ffff800008096348 <panic+0xe0> // b.none I 149.05422547 panic: ffff800008096310: f90023f9 str x25, [sp, #64] E 149.05422547 panic: ffff800008096314: 97fe44ef bl ffff8000080276d0 <panic_smp_self_stop> A panic: ffff80000809634c I 149.05422547 panic: ffff80000809634c: 910102d5 add x21, x22, #0x40 I 149.05422547 panic: ffff800008096350: 52800020 mov w0, #0x1 // #1 E 149.05422547 panic: ffff800008096354: 94166b8b bl ffff800008631180 <bust_spinlocks> N 149.054225518 bust_spinlocks: ffff800008631180: 340000c0 cbz w0, ffff800008631198 <bust_spinlocks+0x18> I 149.054225518 bust_spinlocks: ffff800008631184: f000a321 adrp x1, ffff800009a98000 <pbufs.0+0xbb8> I 149.054225518 bust_spinlocks: ffff800008631188: b9405c20 ldr w0, [x1, #92] I 149.054225518 bust_spinlocks: ffff80000863118c: 11000400 add w0, w0, #0x1 I 149.054225518 bust_spinlocks: ffff800008631190: b9005c20 str w0, [x1, #92] E 149.054225518 bust_spinlocks: ffff800008631194: d65f03c0 ret A panic: ffff800008096358 TODO ---- * Change ETM configuration done in patch #7 to new system configuration manager profile * Change CTI sysfs script to system configuration manager profile * Reading tracedata from crashdump kernel is not tested. * Perf based trace capture and decode is not tested. Linu Cherian (8): dt-bindings: arm: coresight-tmc: Add "memory-region" property coresight: tmc-etr: Add support to use reserved trace memory coresight: core: Add provision for panic callbacks coresight: tmc: Enable panic sync handling coresight: tmc: Add support for reading tracedata from previous boot coresight: tmc: Stop trace capture on FlIn coresight: etm4x: Configure ETM to trigger on panic coresight: cti: Add CTI id for Neoverse N2 core CTI .../bindings/arm/arm,coresight-tmc.yaml | 13 + drivers/hwtracing/coresight/coresight-core.c | 32 ++ .../hwtracing/coresight/coresight-cti-core.c | 1 + .../coresight/coresight-etm4x-core.c | 18 +- drivers/hwtracing/coresight/coresight-etm4x.h | 26 ++ .../hwtracing/coresight/coresight-tmc-core.c | 146 +++++++++- .../hwtracing/coresight/coresight-tmc-etf.c | 126 +++++++- .../hwtracing/coresight/coresight-tmc-etr.c | 274 +++++++++++++++++- drivers/hwtracing/coresight/coresight-tmc.h | 48 +++ include/linux/coresight.h | 25 ++ 10 files changed, 701 insertions(+), 8 deletions(-) Links: 1. https://lore.kernel.org/linux-arm-kernel/20230818082112.554638-1-anshuman.khandual@arm.com/ 2. https://lore.kernel.org/linux-arm-kernel/20230823042948.12879-1-lcherian@marvell.com/T/