From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 849E2C43334 for ; Wed, 29 Jun 2022 18:25:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=trv8Cno5En/GLOpXXYkvQPK8L+Bs6WgLZm/E9NeKdRc=; b=y0Yv1NAvKTNp9l pUIR9fbTDz8Y8w2gEgL7PrQRycJEo2AcCNwcZs5wNxjrKeOcXiTU/p4kozDe/GSmc/FlYgXhkLYiq KzZNE7WODUYcqAU49CeXMziGLgorjgMWT4iNf2LWsHWfvzZAn8lfx+lJKSUA5co2KZsO1mkfnp32e 5f6OszpL0tZi+twWRzGPeyyoQb8zBJpLPDRBjCCXY1AKaCfFNXR+uctKvXrBrgcQzCz8EJ7GexrpX j2lgnF1axO2GAh2RAzmjHx/nnKNoN1laxVaYG84HKNxrHeZP/QX+sEI15sxhWW7g925l4lXirhBKo FhHuGHxVYQDpZCRpFe1A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o6cLv-00DTup-PG; Wed, 29 Jun 2022 18:23:52 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o6cHs-00DSLg-Dw for linux-arm-kernel@lists.infradead.org; Wed, 29 Jun 2022 18:19:42 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3EE561480; Wed, 29 Jun 2022 11:19:36 -0700 (PDT) Received: from e120937-lin (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 01E573F5A1; Wed, 29 Jun 2022 11:19:34 -0700 (PDT) Date: Wed, 29 Jun 2022 19:19:32 +0100 From: Cristian Marussi To: Jim Quinlan Cc: open list , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , Sudeep Holla , Florian Fainelli , Vincent Guittot , Lukasz Luba Subject: Re: [PATCH 0/2] Add SCMI full message tracing Message-ID: References: <20220623145533.2882688-1-cristian.marussi@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220629_111940_613182_1D57CD1F X-CRM114-Status: GOOD ( 30.51 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Jun 27, 2022 at 03:05:57PM -0400, Jim Quinlan wrote: > On Thu, Jun 23, 2022 at 10:55 AM Cristian Marussi > wrote: > > > > Hi, > > > > after a few recent troubles handling too strictly out-of-spec replies from > > SCMI servers deployed in the wild, I though it could have been useful to > > have a basic way to dump at will the effective full payloads of successfuly > > transmitted/received SCMI messages. > > > > The existing SCMI traces already collect a bunch of information about SCMI > > message exchanges but they do NOT keep any payload information: this is > > certainly preferable most of the time since dumping full SCMI messages to > > the trace buffer involves a full copy of the payload. > > > > For this reason I added a new distinct trace_scmi_msg_dump with this series > > in order to be able to selectively enable at will message dumping only when > > required. > > > > Only successfully transmitted and received (valid) xfers are dumped. > > > > At first I was thinking about just dumping raw header and payload, but in > > order to make the log a bit more human readable (without the need of > > tooling to parse the log), I added some parsing/interpretation of the > > header, so that the final result is something like: > > > > root@deb-guest:~# echo 1 > /sys/kernel/debug/tracing/events/scmi/scmi_msg_dump/enable > > root@deb-guest:~# cat /sys/kernel/debug/tracing/trace_pipe > > > > (my annotations non on traces =>>) proto type cmd seq status payload > > | | | | | | > > ++ cmd/reply | | | | | | > > cat-224 [002] ..... 147.755847: scmi_msg_dump: [0x15]:CMND:[0x06]:[0021]:[0]: 0000000000000000 > > -0 [000] d.h2. 147.758311: scmi_msg_dump: [0x15]:RESP:[0x06]:[0021]:[0]: 25000000000000000000000000000000 > >I'll probably still use a script, but > as you are keep > > > > ++ cmd/reply/delayed > > cat-223 [001] ..... 122.384192: scmi_msg_dump: [0x15]:CMND:[0x06]:[0020]:[0]: 0100000001000000 > > -0 [000] d.h2. 122.405548: scmi_msg_dump: [0x15]:RESP:[0x06]:[0020]:[0]: > > -0 [000] d.h2. 122.425839: scmi_msg_dump: [0x15]:DLYD:[0x06]:[0020]:[0]: 01000000a05a320000000000efbeaddefecafeca > > > > > > ++ enable notif/notif > > iio_generic_buf-233 [003] ..... 522.399690: scmi_msg_dump: [0x15]:CMND:[0x0A]:[0024]:[0]: 0800000003000000 > > -0 [000] dNh2. 522.417778: scmi_msg_dump: [0x15]:RESP:[0x0A]:[0024]:[0]: 00000000 > > -0 [000] d.h2. 522.500945: scmi_msg_dump: [0x15]:NOTI:[0x01]:[0000]:[0]: 000000000800000008daffffffffffff0040d3a45d46fb1610daffffffffffff0040d3a45d46fb1618daffffffffffff0040d3a45d46fb16 > > > > Payload is dumped as it comes through byte-by-byte without any endianity > > conversion to avoid further load on the system. > > > > Any thoughs ? > > Hi Christian, > I haven't tested this but the format looks good to me. I have a > couple of minor suggestions > below. > Hi Jim, thanks for having a look. > As all numbers are hex, consider dropping the '0x'. BTW, the seq > value (eg [0020]) is hex but does not have '0x'. > Yes indeed, good point. > Some TP_printk()s use this style: > > scmi_msg_dump: pt=15 t=CMND cmd=06 seq=0021 s=0 pyld=12345678abcdef > > which allows one to easily grep, for example, for all non-zero returns > > grep 's=[^0]' > > This format is also easy to parse with a script: strip the preamble, > split on whitespace, and then split on '=' to get the [key, value] > pairs. In fact having a grep-friendly format is better. Thanks for your feedback, I'll wait to see if someone else wants to chime in and repost. Thanks, Cristian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel