Skip to content

Conversation

@marc-hb
Copy link
Collaborator

@marc-hb marc-hb commented Apr 29, 2021

Having the same -w parameter for two different sleeps in the same
iteration made no sense.

It was not clear what the purpose of this first sleep was, it has been in
multiple-pipeline-capture/playback.sh since the dawn of time (= commit
39cd964) For sure this first sleep was helping hide
"uninterruptible state" bug #472 by giving the DSP more time to wake up!

More recently it was found after merging and reverting an earlier
version of this (PR #543 / commit f93a3c8) that this first sleep
was (accidentally?) giving more time for processes to actually
disappeared after being killed at the end of a test round and not
pollute the next test iteration. Make that clearer by moving the first
sleep to the end of the iteration, right after the kills and hardcode to
one second.

Having the same -w parameter for two different sleeps in the same
iteration made no sense.

It was not clear what the purpose of this first sleep was, it has been in
multiple-pipeline-capture/playback.sh since the dawn of time (= commit
39cd964) For sure this first sleep was helping hide
"uninterruptible state" bug thesofproject#472 by giving the DSP more time to wake up!

More recently it was found after merging and reverting an earlier
version of this (PR thesofproject#543 / commit f93a3c8) that this first sleep
was (accidentally?) giving more time for processes to actually
disappeared after being killed at the end of a test round and not
pollute the next test iteration. Make that clearer by moving the first
sleep to the end of the iteration, right after the kills and hardcode to
one second.

Signed-off-by: Marc Herbert <marc.herbert@intel.com>
@marc-hb
Copy link
Collaborator Author

marc-hb commented Apr 29, 2021

In https://sof-ci.01.org/softestpr/PR671/build685/devicetest/ I hardcoded the loop count to 50 and did not see any pollution of one iteration to the next like in #543 (comment)

@marc-hb marc-hb changed the title [TEST] multiple-pipeline: simplify sleeps multiple-pipeline: simplify sleeps Apr 29, 2021
@marc-hb marc-hb requested a review from keqiaozhang April 29, 2021 05:48
@keqiaozhang
Copy link
Contributor

Verified this PR on several TGL platform, sleep 1 is enough for process to clean up completely.

@marc-hb marc-hb marked this pull request as ready for review April 29, 2021 06:23
@marc-hb marc-hb requested a review from a team as a code owner April 29, 2021 06:23
@marc-hb
Copy link
Collaborator Author

marc-hb commented Apr 29, 2021

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants