Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6;
Message-ID: <fafd728b-1489-4856-ced3-6759fbda2c6f@arm.com>
Date:   Fri, 15 Sep 2023 14:50:28 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.0
Subject: Re: [RFC PATCH v3 0/8] Coresight for Kernel panic and watchdog reset
Content-Language: en-US
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, sgoutham@marvell.com,
        gcherian@marvell.com
References: <20230904050548.28047-1-lcherian@marvell.com>
From:   James Clark <james.clark@arm.com>
In-Reply-To: <20230904050548.28047-1-lcherian@marvell.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk


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
>