| Message ID | 20220630173135.2086631-1-cristian.marussi@arm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add SCMI full message tracing | expand |
On Thu, Jun 30, 2022 at 06:31:33PM +0100, 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 > successfully 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. Looks good to me. I would like to hear from Jim if possible. I plan to merge this ASAP.
Hi,
LGTM, I appreciate this change. For testing, I fed your sample output to this:
perl -MData::Dumper -nae 's/^.+scmi_msg_dump:// && print Dumper
{ (map { split /=/; } split" ") }' < scmi.txt
which gives this
$VAR1 = {
'pt' => '15',
'seq' => '0000',
'pyld' =>
'000000000800000009daffffffffffff008268d4c075fd1611daffffffffffff008268d4c075fd1619daffffffffffff008268d4c075fd16',
'msg_id' => '01',
's' => '0',
't' => 'NOTI'
};
which is what I wanted. BTW, if I ever write a script that would
take this SCMI trace text and
decode it to nice cmd names and arguments -- where would I submit such a script?
Thanks and Regards,
Jim Quinlan
Broadcom STB
On Fri, Jul 1, 2022 at 9:54 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Thu, Jun 30, 2022 at 06:31:33PM +0100, 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
> > successfully 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.
>
> Looks good to me. I would like to hear from Jim if possible. I plan to
> merge this ASAP.
>
> --
> Regards,
> Sudeep
On Fri, Jul 01, 2022 at 11:03:38AM -0400, Jim Quinlan wrote: > Hi, > LGTM, I appreciate this change. For testing, I fed your sample output to this: > Thanks! > perl -MData::Dumper -nae 's/^.+scmi_msg_dump:// && print Dumper > { (map { split /=/; } split" ") }' < scmi.txt > > which gives this > > $VAR1 = { > 'pt' => '15', > 'seq' => '0000', > 'pyld' => > '000000000800000009daffffffffffff008268d4c075fd1611daffffffffffff008268d4c075fd1619daffffffffffff008268d4c075fd16', > 'msg_id' => '01', > 's' => '0', > 't' => 'NOTI' > }; > which is what I wanted. BTW, if I ever write a script that would > take this SCMI trace text and > decode it to nice cmd names and arguments -- where would I submit such a script? > I am not 100% sure. After reading this, the first thoughts were scripts/ or tools/scripts but looking at the content I am less sure about latter. Worth posting and then check what people have to say once this lands upstream. Or even once this is merged into -next officially.
On Thu, 30 Jun 2022 18:31:33 +0100, Cristian Marussi wrote: > 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 > successfully 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. > > [...] Applied to sudeep.holla/linux (for-next/scmi), thanks! [1/2] include: trace: Add SCMI full message tracing https://git.kernel.org/sudeep.holla/c/2bd0467074 [2/2] firmware: arm_scmi: Use new SCMI full message tracing https://git.kernel.org/sudeep.holla/c/b60e088682 -- Regards, Sudeep
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 successfully 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. Following the advice from Jim, 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 ++ cmd/reply sugov:0-257 [000] ..... 401.954788: scmi_msg_dump: pt=13 t=CMND msg_id=07 seq=0082 s=0 pyld=0000000000000000 <idle>-0 [000] d.h2. 401.955085: scmi_msg_dump: pt=13 t=RESP msg_id=07 seq=0082 s=0 pyld= ++ cmd/reply/delayed cat-263 [001] ..... 471.533806: scmi_msg_dump: pt=15 t=CMND msg_id=06 seq=008A s=0 pyld=0100000001000000 <idle>-0 [000] d.h2. 471.554001: scmi_msg_dump: pt=15 t=RESP msg_id=06 seq=008A s=0 pyld= <idle>-0 [000] d.h2. 471.574102: scmi_msg_dump: pt=15 t=DLYD msg_id=06 seq=008A s=0 pyld=01000000a05a320000000000efbeaddefecafeca ++ enable notif/notif iio_generic_buf-282 [000] ..... 535.327307: scmi_msg_dump: pt=15 t=CMND msg_id=0A seq=00AB s=0 pyld=0800000003000000 <idle>-0 [000] d.h2. 535.327561: scmi_msg_dump: pt=15 t=RESP msg_id=0A seq=00AB s=0 pyld=00000000 <idle>-0 [000] d.h2. 535.334421: scmi_msg_dump: pt=15 t=NOTI msg_id=01 seq=0000 s=0 pyld=000000000800000008daffffffffffff008268d4c075fd1610daffffffffffff008268d4c075fd1618daffffffffffff008268d4c075fd16 <idle>-0 [000] d.h2. 535.434649: scmi_msg_dump: pt=15 t=NOTI msg_id=01 seq=0000 s=0 pyld=000000000800000009daffffffffffff008268d4c075fd1611daffffffffffff008268d4c075fd1619daffffffffffff008268d4c075fd16 Payload is dumped as it comes through byte-by-byte without any endianity conversion to avoid further load on the system. Thanks, Cristian --- V1 --> V2 - changed dumping format Cristian Marussi (2): include: trace: Add SCMI full message tracing firmware: arm_scmi: Use new SCMI full message tracing drivers/firmware/arm_scmi/driver.c | 21 ++++++++++++++++++++ include/trace/events/scmi.h | 31 ++++++++++++++++++++++++++++++ 2 files changed, 52 insertions(+)