-
Notifications
You must be signed in to change notification settings - Fork 349
[mtl-006] Port multicore fix to mtl-006-drop-stable branch #8179
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[mtl-006] Port multicore fix to mtl-006-drop-stable branch #8179
Conversation
|
@serhiy-katsyuba-intel @tmleman @abonislawski This PR includes #8149 on main branch to fix issue #8155 Can you please review? |
|
Build failed, can you fix the build errors? I can quickly verify if this really fix the multicore problem. |
|
I fixed the build error and checking with mtl-006-stable-drop diff --git a/src/ipc/ipc4/handler.c b/src/ipc/ipc4/handler.c
index 845b71fa6b9c..443e593f0d76 100644
--- a/src/ipc/ipc4/handler.c
+++ b/src/ipc/ipc4/handler.c
@@ -67,7 +67,7 @@ static struct ipc4_msg_data msg_data;
/* fw sends a fw ipc message to send the status of the last host ipc message */
static struct ipc_msg msg_reply = {0, 0, 0, 0, LIST_INIT(msg_reply.list)};
-static struct ipc_msg msg_notify = {0, 0, 0, 0, LIST_INIT(msg_notify.list)}};
+static struct ipc_msg msg_notify = {0, 0, 0, 0, LIST_INIT(msg_notify.list)};
/*
* Global IPC Operations. |
|
unfortunately, different IPC timeout came up when GLB_CREATE_PIPELINE |
5f6c474 to
3a5bdfa
Compare
|
Let me check 006, I only tested main. Thanks! |
|
with 2nd push, there is no build error, but back to MOD_SET_DX error |
|
Add more debug method and find the fw hang after set_dx to disable secondary core. It will be always failed with create_pipeline after set_dx |
tmleman
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
lgirdwood
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mwasko @marcinszkudlinski fyi merged into main last week and results good.
|
@RanderWang there is quite a lof of CI sof-ci/jenkins/pr-device-test/main-ace failures on MTL, can you clarify this? |
3a5bdfa to
3dc2a23
Compare
|
The FW building was failed with error but it has nothing to do with my PR. /zep_workspace/sof/src/schedule/zephyr_domain.c:26:10: fatal error: zephyr/timeout_q.h: No such file or directory
26 | #include <zephyr/timeout_q.h>
| ^~~~~~~~~~~~~~~~~~~~
compilation terminated. |
becf889 to
d32f1f2
Compare
d32f1f2 to
3a06939
Compare
bf7e8ae to
37bd281
Compare
|
SOFCI TEST |
In multicore case, IPC message is dispatched from primary core to secondary core which send reply message to host. Primary core will do nothing if IPC_TASK_SECONDARY_CORE is set. But in rare case, the secondary code finish the reply message and clear this flag before the ipc thread in primary core check this flag, then primary core also send reply message again. This results to the reply message being inserted two times in ipc message list and infinite loop when visiting the list. We don't need to init reply message since it is initialized after deleting from the ipc list. Signed-off-by: Rander Wang <rander.wang@intel.com>
Use list_is_empty to check the message is queued or not. The notify message is initialized to empty after deleting from the ipc msg list. We use the same idea in ipc_msg_send. Signed-off-by: Rander Wang <rander.wang@intel.com>
3dc2a23 to
593d985
Compare
|
the error only happened on mtl-sdw device and it is a regression issue on 006branch. @keqiaozhang is working on it. |
please check #8143 and #8149
All CI multi-core tests pass on main branch!