[BUG] [ADLP] KMOD test failed on ADLP_GMB_I2S_ZEPHYR #5733
Comments
keqiaozhang
added
bug
|
@keqiaozhang is this bug still seen? |
Yes, with 100% reproduction rate. |
|
Moving priority to P1 to make sure such critical boot issues are handled. This is not optional, one of these days we are doing to see a boot failure in the field that could have been prevented by internal testing. @mengdonglin @lgirdwood this has to be assigned to someone and solved. |
|
This issue only happens with Zephyr firmware, no such issue with SOF-XTOS. |
|
@lgirdwood this bug should be transferred to SOF then? |
|
Moving to FW. |
|
More severe kmod crashes just spotted in |
marc-hb
added
the
Intel Linux Daily tests
|
@lyakh any updates? It always fails in CI. |
@keqiaozhang I'm still debugging this. I think I have to discuss with Zephyr developers more actively |
|
@lyakh ping any updates ? |
@lgirdwood a few updates, yes. Mostly I now have two lines of working with this:
|
|
I was able to reproduce the sporadic core boot problem with a modified native Zephyr test, that bug is now tracked in zephyrproject-rtos/zephyr#46372 |
|
An update: a brute-force fix is available: zephyrproject-rtos/zephyr#46372 (comment) but a clean fix still has to be developed |
To power down secondary cores on cAVS 2.5 platforms the primary core enables the power-saving mode for the respective secondary core and waits until that core enters idle() and executes the waiti instruction at which point the core should enter a lower-power mode. However, that core can then also automatically wake up and execute its reset path if, e.g. an interrupt is delivered to it. However, it isn't entirely clear which events are able to wake up cores from that state. Disabling interrupts on the interrupt controller didn't seem to prevent that from happening completely. In particular a specific ADL notebook seems to be susceptible to this problem. Checking for such sporadic boots and returning to idle fixes the problem. BugLink: #46372 BugLink: thesofproject/sof#5733 Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
To power down secondary cores on cAVS 2.5 platforms the primary core enables the power-saving mode for the respective secondary core and waits until that core enters idle() and executes the waiti instruction at which point the core should enter a lower-power mode. However, that core can then also automatically wake up and execute its reset path if, e.g. an interrupt is delivered to it. However, it isn't entirely clear which events are able to wake up cores from that state. Disabling interrupts on the interrupt controller didn't seem to prevent that from happening completely. In particular a specific ADL notebook seems to be susceptible to this problem. Checking for such sporadic boots and returning to idle fixes the problem. (cherry picked from commit 3748bdc) Original-BugLink: zephyrproject-rtos/zephyr#46372 Original-BugLink: thesofproject/sof#5733 Original-Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> GitOrigin-RevId: 3748bdc Change-Id: I44254684b71f0a73a1899e81c646cd125b2d87c2 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/zephyr/+/3742498 Commit-Queue: Fabio Baltieri <fabiobaltieri@google.com> Tested-by: Fabio Baltieri <fabiobaltieri@google.com> Tested-by: CopyBot Service Account <copybot.service@gmail.com> Reviewed-by: Fabio Baltieri <fabiobaltieri@google.com>
|
Conformed that this issue is fixed by zephyrproject-rtos/zephyr#46587 and it's not reproducible on GMB, closing this bug. |
To power down secondary cores on cAVS 2.5 platforms the primary core enables the power-saving mode for the respective secondary core and waits until that core enters idle() and executes the waiti instruction at which point the core should enter a lower-power mode. However, that core can then also automatically wake up and execute its reset path if, e.g. an interrupt is delivered to it. However, it isn't entirely clear which events are able to wake up cores from that state. Disabling interrupts on the interrupt controller didn't seem to prevent that from happening completely. In particular a specific ADL notebook seems to be susceptible to this problem. Checking for such sporadic boots and returning to idle fixes the problem. BugLink: zephyrproject-rtos/zephyr#46372 BugLink: thesofproject/sof#5733 Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Describe the bug
IPC tx timed out for DMA_PARAMS_EXT when inserting audio modules. This issue only observed on this platform.
This issue only happens with Zephyr firmware, no such issue with SOF-XTOS.
To Reproduce
$ sof-test/tools/kmod/sof_remove.sh
$ sof-test/tools/kmod/sof_insert.sh
Reproduction Rate
100%
Expected behavior
No IPC errors during the kmod test
Impact
Failed to setup widget PIPELINE.14.SSP2.IN
Environment
2）* Topology: sof-adl-max98390-rt5682.tplg
Screenshots or console output
dmesg:
The text was updated successfully, but these errors were encountered: