Open gbarkadiusz opened 1 year ago
@kv2019i any idea what is going on here?
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.
This is still reproduced.
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.
We still got reproduction
@nashif I can reproduce this locally. This seems to be a test case problem. The fault happens in sys_clock_announce() and I cna't really spot anything wrong in the driver. The test case will need a fix though.
I can make the test pass if I remove the sem_take and sem_give and add a simple sleep, so there's something wrong with the semaphore use in this test:
pattern not found in rx buffer
Sleep before cleanup
PASS - test_adsp_ssp_transfer in 2.009 seconds
===================================================================
TESTSUITE adsp_ssp succeeded
I can also make the test pass with semaphores in place by adding a delay (see draft PR #71452 ). This doesn't make much sense, need to continue debug.
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.
@kv2019i any progress with this one ?
@ceolin after applying this workaround in https://github.com/zephyrproject-rtos/zephyr/pull/71452 power management kicks in and locks the system, i.e. no further tests are possible, but we need to see why this delay is needed in the first place.
I am going to check. Maybe secondary cores are not online and this sempahore is causing the system to deep sleep.
@ceolin any update regarding this one ?
That is weird, cav25 has only one power state and it should be triggered by this sleep because of its residency time.
https://github.com/zephyrproject-rtos/zephyr/pull/77581 -> This fix the problem of the system sleeps indefinitely.
@kv2019i @nashif there is something really weird happening in this test and there is a chance the problem is in the kernel. What the sleep does is allowing the dma transfer to happen before the thread trying to acquire the semaphore. The callback is called and does k_sem_give()
before the test does k_sem_take()
so there is not contention needed.
To make things even more weird, if we run it with only one core enabled (CONFIG_MP_MAX_NUM_CPUS=1
) the DMA transfer does NOT finish but the test ignores it and pass.
Describe the bug The tests/boards/intel_adsp/ssp/boards.intel_adsp.ssp fails.
To Reproduce
scripts/twister -W -p intel_adsp_cavs25 --device-testing --hardware-map <path_to>/cavs/cavs.map -s tests/boards/intel_adsp/ssp/boards.intel_adsp.sspf -v
Logs and console output
Handler.log contains.
Environment (please complete the following information):