Enable mtrace #956

keqiaozhang · 2022-09-09T08:11:48Z

No description provided.

keqiaozhang · 2022-09-13T01:55:21Z

Tested with different FW model:http://sof-ci.sh.intel.com/#/result/planresultdetail/15252. looks like everything is working fine.

kv2019i

Looks good! Couple of comments inline that can be fixed in a follow-up. Tested this locally and seems to work fine.

kv2019i · 2022-09-13T11:50:34Z

case-lib/lib.sh


+is_ipc4_zephyr(){
+    local firmware_path firmware_name znum
+    fw_path=/sys/module/snd_sof_pci/parameters/fw_path


The above doesn't work if fw_path is not set. At least I had a local setup where I just use the standard path assumed by kernel for IPC4 FW.

Maybe if fw_path is NULL, check for /lib/firmware/intel/avs/"$platf"/dsp_basefw.bin . This is what is in SOF kernel driver by default unless fw_path is passed as a module parameter.

Above can be done in a seperate follow-up PR.

Yes, I can do that, but we need to solve one problem, the full fw_path should be /lib/firmware/intel/avs/"$platf"/"$key_type"/dsp_basefw.bin.

For example, the full fw path of TGLU_UP_HDA_IPC4ZPH is /lib/firmware/intel/avs/tgl/community/dsp_basefw.bin. The key_type is defined in community boards :https://github.com/thesofproject/linux/blob/topic/sof-dev/sound/soc/sof/sof-pci-dev.c#:~:text=/*%20all%20Up,%7D%3B.

I can use the DMI info to get the key_type, but better to let the kernel driver to expose the fw_path as Marc suggested below.

kv2019i · 2022-09-13T11:53:16Z

case-lib/lib.sh

-        dlogi 'SOF logs collection is globally disabled because DUT is running IPC4 mode'
+    if ipc4_used && ! is_ipc4_zephyr; then
+        # mtrace and sof-logger are not supported for closed source IPC4 Firmware
+        dlogi 'Currenly trace loggers are not supported for closed source IPC4 firmware.'


Let's just put "IPC4 FW logging only support with SOF Zephyr build"

"Currenly" --> "Currently"?
Edit: Scratch that, I was looking at an outdated file.

marc-hb · 2022-09-13T23:09:31Z

case-lib/lib.sh

    printf '%s' "$ldcFile"
 }

+func_logger_collect()


Suggested change

func_logger_collect()

func_sof_logger_collect()

We have too many logging tools, important to label them well.

marc-hb · 2022-09-13T23:38:21Z

case-lib/lib.sh

+    ipc4_used || return 1
+
+    znum=$(strings "/lib/firmware/$firmware_path/$firmware_name" | grep -c -i zephyr)
+    test "$znum" -gt 10


I recognize this code from the existing is_zephyr() function... which depends on the sof-logger .ldc file.

Please don't create a new, hidden and different is_zephyr() function here while keeping the old one. We need a single is_zephyr() function.

Either the old is_zephyr() function is still OK (because we still depend on sof-logger for DMA logs) and you call it here. Or it's not OK and you fix it; don't leave all the other is_zephyr() users broken.

To find the firmware file you can try some combination of ./tools/sof-dump-status.py -P and ./tools/sof-dump-status.py -p. Again these are used in many other places, so if they don't work then them must be fixed.

@kv2019i , @plbossart, @ujfalusi sof-test needs something like /sys/module/snd_sof_pci/parameters/fw_path but reliable that it can count on, can the kernel expose that? Same thing for the topology: up to now sof-test/tools/sof-get-default-tplg.sh has been grepping journalctl; that's a horrible and unreliable hack.

PS: actually the Linux kernel request_firmware API should expose all the firmware files it has loaded from a filesystem, this sort of "manifest" seems like a bare minimum from a security perspective but that could take years.

Please don't create a new, hidden and different is_zephyr() function here while keeping the old one. We need a single is_zephyr() function.

Yes, I also considered to reuse is_zephyr() function, but it depends on the sof-logger .ldc file. But IPC4 firmware has
no ldc file. if we want to reuse this function, we need to switch to using firmware binary instead of ldc file.

To find the firmware file you can try some combination of ./tools/sof-dump-status.py -P and ./tools/sof-dump-status.py -p

./tools/sof-dump-status.py -P only works for IPC3 not IPC4. Part of path is fixed as /lib/firmware/intel/sof/, it only check if the DUT is community board, if yes, the fw_path will be combined to /lib/firmware/intel/sof/community

can the kernel expose that? Same thing for the topology: up to now sof-test/tools/sof-get-default-tplg.sh has been grepping journalctl; that's a horrible and unreliable hack.

I totally agree with this proposal, then we can get the reliable fw_path from the journalctl.

I meant: "can you please add mtrace support to check-sof-logger first"?

I‘m trying to add mtrace in check-sof-logger.sh, but I realized that mtrace-reader.py should run while tests are running. If no tests are running, the log outputs will be empty.

In check-sof-logger.sh, we reload sof driver first, then collect and analyze the logs, which is not suitable for mtrace.
Do we need to start mtrace while reloading the driver?

I'm not sure if it's a mtrace limitation.
@kv2019i , please help to explain it here.

I'm not sure I fully understand your point.
IPC3 and IPC4 are using a completely different path:
IPC3: /lib/firmware/intel/sof or /lib/firmware/intel/sof/community/
IPC4: /lib/firmware/intel/sof-ipc4/$platform/community or /lib/firmware/intel/sof-ipc4/$platform/debug/

So if we add a function like is_fw_file_zephyr($filename) -> return true/false, we first need to check ipc4_used or not.
If we don't know the IPC type, then it's hard for us to know the specific fw_path,
So the process should be:

check ipc type ipc4_used

get the fw_path

check if the fw is zephyr

Almost the same steps as I did in function is_ipc4_zephyr.

So if we add a function like is_fw_file_zephyr($filename) -> return true/false, we first need to check ipc4_used or not.
...
Almost the same steps as I did in function is_ipc4_zephyr

Yes but is_ipc4_zephyr is monolithic hence unscalable and unmaintainable. Break it down in smaller, modular, re-usable and maintainable functions.

Sorry, I didn't figure out a better solution to break is_ipc4_zephyr down in smaller.

I'm thinking to use firmware file to check zephyr in is_zephyr instead of ldc file.
We can refine this part after thesofproject/linux#3867 is supported.

Then combine these two functions ipc4_used + is_zephyr to replace is_ipc4_zephyr.

any other suggestions?

I'm thinking to use firmware file to check zephyr in is_zephyr instead of ldc file.

Yes, this is what I suggested above: is_fw_file_zephyr($filename). We unfortunately need two different is_zephyr_XXX() functions for now. Better make that obvious rather than hide it buried deep in a big, monolithic is_ipc4_zephyr() that looks like it's calling the usual is_zephyr() while doing something different behind the scenes.

marc-hb

As with cavstool before, can you please fix check-sof-logger.sh first? This will reduce the impact when something goes wrong (as it happened with cavstool) and it should be done anyway.

Note the earlier cavstool attempt in sof-test #897 (to be abandoned?). It has relevant context about func_lib_start_log_collect() and others.

marc-hb · 2022-09-13T23:53:12Z

case-lib/lib.sh

+    ipc4_used || return 1
+
+    znum=$(strings "/lib/firmware/$firmware_path/$firmware_name" | grep -c -i zephyr)
+    test "$znum" -gt 10


To find the firmware file you can try some combination of ./tools/sof-dump-status.py -P and ./tools/sof-dump-status.py -p. Again these are used in many other places, so if they don't work then them must be fixed.

@kv2019i , @plbossart, @ujfalusi sof-test needs something like /sys/module/snd_sof_pci/parameters/fw_path but reliable that it can count on, can the kernel expose that? Same thing for the topology: up to now sof-test/tools/sof-get-default-tplg.sh has been grepping journalctl; that's a horrible and unreliable hack.

PS: actually the Linux kernel request_firmware API should expose all the firmware files it has loaded from a filesystem, this sort of "manifest" seems like a bare minimum from a security perspective but that could take years.

marc-hb · 2022-09-13T23:54:19Z

case-lib/lib.sh

-        log_file=$LOG_ROOT/slogger.txt
-        log_opt="-t"
-        func_logger_collect "$log_file" "$log_opt"
+        if is_ipc4_zephyr; then


Suggested change

if is_ipc4_zephyr; then

if is_zephyr && is_ipc4; then

marc-hb · 2022-09-13T23:56:50Z

case-lib/hijack.sh


    fi

+    if is_ipc4_zephyr; then


Suggested change

if is_ipc4_zephyr; then

if is_zephyr && is_ipc4; then

marc-hb · 2022-09-14T20:40:41Z

Another important problem: there are only 3 platforms tested in https://sof-ci.01.org/softestpr/PR956/build135/devicetest/ and they're ALL part of the same audio hardware generation and they are all Zephyr. This is especially problematic for a PR like this one that has messy is_zephyr copy/paste/diverge.

Every sof-test PR needs this : https://sof-ci.01.org/linuxpr/PR3860/build714/devicetest/ (part of thesofproject/linux#3860), we can't wait nightly tests to discover regressions.

keqiaozhang · 2022-09-15T13:42:34Z

Another important problem: there are only 3 platforms tested

I created a new test plan and covered all our test configs: xtos-ipc3, zephyr-ipc3. zephyr-ipc4 and cavs-ipc4:
http://sof-ci.sh.intel.com/#/result/planresultdetail/15402

The results look good. All failures are identified as known issues(sof-logger and IPC4 related issues). The new logging tool mtrace works as expected and sof-logger is not effected.

kv2019i

Seems to work great! And we really, really, really need this as currently we are running blind w.r.t. FW logs in IPC4 test runs.

marc-hb · 2022-09-15T22:32:59Z

I created a new test plan and covered all our test configs: xtos-ipc3, zephyr-ipc3. zephyr-ipc4 and cavs-ipc4:
http://sof-ci.sh.intel.com/#/result/planresultdetail/15402

This is good but it's a once-off. The (messy) logging code in sof-test is going to evolve more and again very soon and not just to fix the regressions introduced by this PR. Also, this URL is not public.

Every sof-test PR needs this : https://sof-ci.01.org/linuxpr/PR3860/build714/devicetest/ (part of thesofproject/linux#3860), we can't wait nightly tests to discover regressions.

keqiaozhang · 2022-09-16T08:16:13Z

can you please fix check-sof-logger.sh first?

sof-logger failure has nothing to do with mtrace, it's only for IPC3 test. they are old known issues and I don't think we can easily fix them all([BUG] IPC timeout in sof-logger-check sof#6042).
check-sof-logger.sh is not suitable for IPC4 test, so we didn't add check-sof-logger.sh to the formal test plan of IPC4, maybe we can add a new case like check-mtrace.sh in future.

kv2019i · 2022-09-19T10:34:23Z

I do agree we need to add a separate test case for mtrace that just checks availability of mtrace. But @marc-hb is that a blocker for this PR?

Btw, I filed a separate enhancement item for kernel to expose the chosen tplg+fw -> thesofproject/linux#3867

kv2019i · 2022-09-19T10:36:15Z

And @marc-hb and @keqiaozhang , please note mtrace (SRAM logging) is not a replacement for sof-logger (DMA based logging). We will still have a new DMA-based logging system for IPC4, which is based on probes. For now, mtrace is just a new way to get lots out with no direct comparison in IPC3 SOF builds.

marc-hb · 2022-09-19T16:01:59Z

can you please fix check-sof-logger.sh first?

sof-logger failure has nothing to do with mtrace

Sorry for the confusion, I meant: "can you please add mtrace support to check-sof-logger first"?

check-sof-logger.sh is not suitable for IPC4 test,

check-sof-logger.sh is generic enough to test any logs from anywhere.

maybe we can add a new case like check-mtrace.sh in future.

Please no copy/paste/diverge.

marc-hb · 2022-09-19T16:05:55Z

I do agree we need to add a separate test case for mtrace that just checks availability of mtrace.

That's exactly what check-sof-logger.sh does for two earlier types of SRAM logging already.

But @marc-hb is that a blocker for this PR?

No but it would be safer. When we added cavstool we started with check-sof-logger which avoided causing a lot of intermittent failures (#897)

kv2019i · 2022-09-20T15:54:36Z

@marc-hb wrote:

I do agree we need to add a separate test case for mtrace that just checks availability of mtrace.
That's exactly what check-sof-logger.sh does for two earlier types of SRAM logging already.

I didn't realize that. So ack, then it's appropriate to also test mtrace.

But @marc-hb is that a blocker for this PR?
No but it would be safer. When we added cavstool we started with check-sof-logger which avoided causing a lot of intermittent failures (#897)

Fair enough. The situation is a bit more urgent now as we have unusual number of P1 bugs open where issues are not happening on all hardware, and we have no visibility to FW logs in current CI results.

marc-hb · 2022-09-20T16:15:34Z

To be clear I'm NOT blocking this PR on a check-sof-logger update. My main problems are with the monolithic and unmaintainable is_ipc4_zephyr() and the recent and major loss of sof-test PR testing in general which is especially relevant here considering the significant refactoring and conditionals. https://sof-ci.01.org/softestpr/PR956/build137/devicetest/ is basically testing a single configuration! I know one version of this PR has been manually tested once but sorry that's way too limited and unsafe. There will be further changes.

keqiaozhang · 2022-09-25T14:05:46Z

@marc-hb I have removed is_ipc4_zephyr function and added a new one is_firmware_file_zephyr.
So we can use is_ipc4 && is_firmware_file_zephyr for IPC4 Zephyr firmware check.

The is_firmware_file_zephyr is not the final version, now we still need to check the ipc type first and use different ways to get the firmware name/path for IPC3 and IPC4. This part will be optimized after driver can expose the FW path to userspace via debugfs, then we can remove function is_zephyr and use is_firmware_file_zephyr instead.

PR testing is passed, will do more test next.

ujfalusi · 2022-09-26T06:50:00Z

case-lib/hijack.sh


    # when sof logger collect is open
-    if [ "X$SOF_LOG_COLLECT" == "X1" ]; then
+    if [ "X$SOF_LOG_COLLECT" == "X1" ] && ! is_ipc4; then


For the sake of consistency:

if [ ! is_ipc4 ] && [ "X$SOF_LOG_COLLECT" == "X1" ]; then

And by reversing the checks it is easier to see that this branch is only for 'not IPC4'.

ujfalusi · 2022-09-26T06:51:31Z

case-lib/hijack.sh


    fi

+    if is_ipc4 && is_firmware_file_zephyr; then


For the sake of consistency:

if [ is_ipc4 ] && [ is_firmware_file_zephyr ]; then

@ujfalusi this syntax is wrong. if is_ipc4 is invoking the is_ipc4() function and checking its return value (as intended). if [ is_ipc4 ] is doing something totally different: it's merely checking whether the "is_ipc4" string is not empty (using a confusing syntax) and it's not invoking any function.

Duplicate of a resolved discussion below. Please resolve all comments like this one or none :-)

ujfalusi · 2022-09-26T06:52:21Z

case-lib/hijack.sh

 {
    local exit_status=${1:-0}
+    local loggerBin wcLog; loggerBin=sof-logger
+    local mtraceBin; mtraceBin=mtrace-reader.py


These can be within their respective if branch?

ujfalusi · 2022-09-26T06:55:31Z

case-lib/lib.sh

-    # Cleaned up by func_exit_handler() in hijack.sh
-    # shellcheck disable=SC2024
-    sudo "${loggerCmd[@]}" > "$logfile" &
+    if [ "X$is_etrace" == "X0" ];then


space between ; and then

ujfalusi · 2022-09-26T07:05:03Z

case-lib/lib.sh

+        }
+    fi
+
+    local mtraceCmd="$MTRACE"


In the last patch you use:

local mtraceBin; mtraceBin=mtrace-reader.py

Which one is the preferred one?

Because in func_mtrace_collect(), the local mtraceCmd="$MTRACE" can be set when testing with IPC4-Zephyr platforms.

So in hijack.sh, if we test on non-IPC4 Zephyr platforms. the mtraceCmd will be empty, we cannot reuse mtraceCmd in hijack.sh. So I set mtrace separately in these 2 scripts.

ujfalusi · 2022-09-26T07:10:31Z

case-lib/lib.sh

-    # 0: DUT runs IPC3 mode, ipc_used return 1(false)
-    # 1: DUT runs IPC4 mode, ipc4_used return 0(true)
+    # 0: DUT runs IPC3 mode, is_ipc4 return 1(false)
+    # 1: DUT runs IPC4 mode, is_ipc4 return 0(true)


The comment does not make any sense
0: DUT runs IPC3 mode, is_ipc4 return 1(false)
1: DUT runs IPC4 mode, is_ipc4 return 0(true)
if ipc_type is 1, this function returns 1 (is_ipc4 is true)

I just checked, for IPC3 mode, the ipc_type is -1(updated).
I don't see any problems here. if ipc_type=1, is_ipc4 function returns 0. which means is_ipc4 is true.
We use || here.

[ "$ipc_type" -eq 1 ] || { return 1 } return 0

OK, I see. Thanks

Would not be easier on the reader to

if [ "$ipc_type" -eq 1 ]; then return 0; fi return 1

|| is useful for one-liner like sanity_check || die or to avoid ! negations (that soon become double negations and that can't be copied to the command line). For basic if/then/else then I agree with @ujfalusi that it is simpler and just more readable to use... a plain if/then/else. One size does not fit all.

case-lib/lib.sh

ujfalusi · 2022-09-26T07:17:04Z

case-lib/lib.sh

+            log_file=$LOG_ROOT/etrace.txt
+            log_opt=""
+            func_sof_logger_collect "$log_file" "$log_opt"
+        }


I'm not following this syntact

It means only non-ipc4 platforms have etrace support.

It's relying on short-circuit evaluation and equivalent to

if ! is_ipc4; then ...

with the difference that ! cannot be copied to the interactive command line whereas this can be.

It reads like in plain English: "either IPC4 is true, OR we do the rest".

It's also more useful for one-liners, here it does not save any line.

I understand why @ujfalusi was confused, I was too. Please change to something like this:

else # once-off etrace collection at end of test if is_ipc4; then dlogi "No end of test etrace collection for IPC4" else log_file=$LOG_ROOT/etrace.txt ... fi fi

kv2019i

Still ok to me. There are a few obviously wrong comments that are probably better to address immediately, but I did not see any showstoppers in functionality side.

case-lib/lib.sh

case-lib/hijack.sh

Signed-off-by: Keqiao Zhang <keqiao.zhang@intel.com>

mtrace is a new logging tool. Tool to stream data from Linux SOF driver mtrace debugfs interface to standard output. Signed-off-by: Keqiao Zhang <keqiao.zhang@intel.com>

keqiaozhang · 2022-09-26T10:22:58Z

Tested this PR with different models, mtrace works as expected on IPC4ZPH platforms(except for the check-sof-logger.sh) and sof-logger is not effected.
http://sof-ci.sh.intel.com/#/result/planresultdetail/15672
http://sof-ci.sh.intel.com/#/result/planresultdetail/15686

2 on device PR tests also passed.

lgirdwood · 2022-09-26T14:23:25Z

All - need some working mtrace sooner rather than later - we can polish it incrementally but we need to start getting the data out.

marc-hb

A couple small changes and we're good to go.

All - need some working mtrace sooner rather than later - we can polish it incrementally but we need to start getting the data out.

This code is incredibly awkward, badly designed and brittle for what it does. @keqiaozhang is doing a delicate and amazing refactoring job but we have 1.9 persons total understanding it and this code is quite critical (as demonstrated by how much this PR is expected). One of the 1.9 persons is me and I have to spend literally 1 hour to make sense of it EVERY TIME I LOOK AT IT so I can't afford to make it worse than it already is.

Thanks everyone for your patience.

marc-hb · 2022-09-26T15:31:28Z

case-lib/lib.sh

-    # 0: DUT runs IPC3 mode, ipc_used return 1(false)
-    # 1: DUT runs IPC4 mode, ipc4_used return 0(true)
+    # 0: DUT runs IPC3 mode, is_ipc4 return 1(false)
+    # 1: DUT runs IPC4 mode, is_ipc4 return 0(true)


|| is useful for one-liner like sanity_check || die or to avoid ! negations (that soon become double negations and that can't be copied to the command line). For basic if/then/else then I agree with @ujfalusi that it is simpler and just more readable to use... a plain if/then/else. One size does not fit all.

case-lib/lib.sh

marc-hb · 2022-09-26T18:58:35Z

case-lib/lib.sh

+            log_file=$LOG_ROOT/etrace.txt
+            log_opt=""
+            func_sof_logger_collect "$log_file" "$log_opt"
+        }


I understand why @ujfalusi was confused, I was too. Please change to something like this:

else # once-off etrace collection at end of test if is_ipc4; then dlogi "No end of test etrace collection for IPC4" else log_file=$LOG_ROOT/etrace.txt ... fi fi

marc-hb · 2022-09-26T19:07:11Z

case-lib/hijack.sh

    # when sof logger collect is open
-    if [ "X$SOF_LOG_COLLECT" == "X1" ]; then
+    if ! is_ipc4 && [ "X$SOF_LOG_COLLECT" == "X1" ]; then
+	local loggerBin wcLog; loggerBin=sof-logger


Please don't change or move this line. This refactoring is complex and risky enough, stick to the bare minimum required.

Add a simple one-line comment like # IPC4 is very different and handled below

Please don't change or move this line. This refactoring is complex and risky enough, stick to the bare minimum required.

Hope I didn't misunderstand your point. PR is updated for

local loggerBin wcLog; loggerBin=sof-logger

Align the name with other similar functions and refine the is_ipc4 function. Signed-off-by: Keqiao Zhang <keqiao.zhang@intel.com>

…phyr This function can check if the running firmware file is built with Zephyr. Signed-off-by: Keqiao Zhang <keqiao.zhang@intel.com>

keqiaozhang · 2022-09-27T10:14:59Z

I have updated this PR based on the last comments. Thanks you all for your review and patience. Tests are running.

[Edit]: in internal test run 15728 mtrace works as expected.

marc-hb · 2022-09-27T16:50:55Z

case-lib/lib.sh

+        else
+            # TODO: let the kernel driver expose the FW path
+            # and get the FW path by grepping journalctl.
+            return 1


We should die here because we don't know the answer. return 1 means "not Zephyr"

Updated with die.

marc-hb

You forgot to squash one fixup commit
I don't see any mtrace output in internal test run 15728

marc-hb · 2022-09-27T16:51:55Z

case-lib/hijack.sh

    # when sof logger collect is open
-    if [ "X$SOF_LOG_COLLECT" == "X1" ]; then
+    if ! is_ipc4 && [ "X$SOF_LOG_COLLECT" == "X1" ]; then
+	local loggerBin wcLog; loggerBin=sof-logger


kv2019i

Tested on local setup and seems to work fine.

…phyr This function can check if the running firmware file is built with Zephyr. Signed-off-by: Keqiao Zhang <keqiao.zhang@intel.com>

The mtrace is only support IPC4 platforms and mtrace should run while tests are running ATM. If mtrace is not running, DSP will stop outputting logs when buffer is full. So we need to keep the mtrace running during the test, or you won't see the error log. Signed-off-by: Keqiao Zhang <keqiao.zhang@intel.com>

need to kill the mtrace-reader.py process after the test to prevent the conflicts between each case. Signed-off-by: Keqiao Zhang <keqiao.zhang@intel.com>

keqiaozhang · 2022-09-28T02:36:04Z

Sorry, I didn't get your point.

I don't see any mtrace output in internal test run 15728

Please check the cases under "TGLU_UP_HDA_IPC4ZPH" and "TGLU_RVP_NOCODEC_IPC4ZPH", I added 2 IPC4 platforms to check the mtrace. Others are XTOS-IPC3, Zephyr-IPC3, CAVS-IPC4.

marc-hb · 2022-09-28T03:34:28Z

Please check the cases under ...

I see it now, sorry for the noise.

keqiaozhang requested a review from a team as a code owner September 9, 2022 08:11

keqiaozhang requested review from aiChaoSONG, kv2019i and marc-hb September 13, 2022 01:51

kv2019i previously approved these changes Sep 13, 2022

View reviewed changes

marc-hb requested changes Sep 13, 2022

View reviewed changes

marc-hb previously requested changes Sep 13, 2022

View reviewed changes

keqiaozhang dismissed kv2019i’s stale review via 2230534 September 14, 2022 07:24

keqiaozhang force-pushed the enable_mtrace branch from 379bd1d to 2230534 Compare September 14, 2022 07:24

kv2019i mentioned this pull request Sep 14, 2022

check-playback: add check for FW performance #959

Closed

kv2019i previously approved these changes Sep 14, 2022

View reviewed changes

keqiaozhang dismissed kv2019i’s stale review via 5801ef2 September 15, 2022 09:32

keqiaozhang force-pushed the enable_mtrace branch from 2230534 to 5801ef2 Compare September 15, 2022 09:32

kv2019i previously approved these changes Sep 15, 2022

View reviewed changes

kv2019i mentioned this pull request Sep 19, 2022

provide interface to query loaded firmware and topology to userspace via debugfs thesofproject/linux#3867

Closed

marc-hb mentioned this pull request Sep 21, 2022

Check for a valid trace for ALL tests #297

Closed

keqiaozhang dismissed kv2019i’s stale review via 3bd55fa September 25, 2022 10:56

keqiaozhang force-pushed the enable_mtrace branch from 5801ef2 to 3bd55fa Compare September 25, 2022 10:56

ujfalusi reviewed Sep 26, 2022

View reviewed changes

kv2019i previously approved these changes Sep 26, 2022

View reviewed changes

case-lib/lib.sh Outdated Show resolved Hide resolved

case-lib/hijack.sh Show resolved Hide resolved

keqiaozhang added 2 commits September 26, 2022 16:43

lib.sh: move logger collection to a function

f08338d

Signed-off-by: Keqiao Zhang <keqiao.zhang@intel.com>

lib.sh: add a function for mtrace collection

7687f20

mtrace is a new logging tool. Tool to stream data from Linux SOF driver mtrace debugfs interface to standard output. Signed-off-by: Keqiao Zhang <keqiao.zhang@intel.com>

keqiaozhang dismissed kv2019i’s stale review via d00eab5 September 26, 2022 09:03

keqiaozhang force-pushed the enable_mtrace branch 2 times, most recently from d00eab5 to 3e51181 Compare September 26, 2022 09:12

kv2019i previously approved these changes Sep 26, 2022

View reviewed changes

marc-hb reviewed Sep 26, 2022

View reviewed changes

keqiaozhang added 2 commits September 27, 2022 17:37

lib.sh: rename the ipc4_used to is_ipc4

8bc5310

Align the name with other similar functions and refine the is_ipc4 function. Signed-off-by: Keqiao Zhang <keqiao.zhang@intel.com>

lib.sh: add a function to check if the firmware file is built with ze…

56cbcdc

…phyr This function can check if the running firmware file is built with Zephyr. Signed-off-by: Keqiao Zhang <keqiao.zhang@intel.com>

keqiaozhang dismissed kv2019i’s stale review via ed57ac9 September 27, 2022 10:12

keqiaozhang force-pushed the enable_mtrace branch from 3e51181 to ed57ac9 Compare September 27, 2022 10:12

marc-hb reviewed Sep 27, 2022

View reviewed changes

marc-hb previously approved these changes Sep 27, 2022

View reviewed changes

kv2019i previously approved these changes Sep 27, 2022

View reviewed changes

keqiaozhang added 3 commits September 28, 2022 09:21

lib.sh: add a function to check if the firmware file is built with ze…

3cd7634

…phyr This function can check if the running firmware file is built with Zephyr. Signed-off-by: Keqiao Zhang <keqiao.zhang@intel.com>

hijack.sh: kill the mtrace after test

9c926a4

need to kill the mtrace-reader.py process after the test to prevent the conflicts between each case. Signed-off-by: Keqiao Zhang <keqiao.zhang@intel.com>

keqiaozhang dismissed stale reviews from kv2019i and marc-hb via 9c926a4 September 28, 2022 02:31

keqiaozhang force-pushed the enable_mtrace branch from ed57ac9 to 9c926a4 Compare September 28, 2022 02:31

marc-hb approved these changes Sep 28, 2022

View reviewed changes

keqiaozhang merged commit c0729e8 into thesofproject:main Sep 29, 2022

marc-hb added the area:logs Log and results collection, storage, etc. label Jun 30, 2023

Enable mtrace #956

Enable mtrace #956

Uh oh!

Conversation

keqiaozhang commented Sep 9, 2022

Uh oh!

keqiaozhang commented Sep 13, 2022

Uh oh!

kv2019i left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

greg-intel Sep 14, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

keqiaozhang Sep 14, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marc-hb Sep 16, 2022 • edited by keqiaozhang Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marc-hb Sep 19, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marc-hb left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marc-hb commented Sep 14, 2022

Uh oh!

keqiaozhang commented Sep 15, 2022

Uh oh!

kv2019i left a comment

Choose a reason for hiding this comment

Uh oh!

marc-hb commented Sep 15, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

keqiaozhang commented Sep 16, 2022

Uh oh!

kv2019i commented Sep 19, 2022

Uh oh!

kv2019i commented Sep 19, 2022

Uh oh!

marc-hb commented Sep 19, 2022

greg-intel Sep 14, 2022 •

edited

Loading

keqiaozhang Sep 14, 2022 •

edited

Loading

marc-hb Sep 16, 2022 •

edited by keqiaozhang

Loading

marc-hb Sep 19, 2022 •

edited

Loading

marc-hb left a comment •

edited

Loading

marc-hb commented Sep 15, 2022 •

edited

Loading

marc-hb commented Sep 19, 2022 •

edited

Loading

marc-hb commented Sep 20, 2022 •

edited

Loading