You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG] multiple platforms and topologies: multiple-pause-resume failures with "nothing to copy" #10116
Describe the bug
Running the "multiple-pause-resume-50" test on PTL with the nocodec topology fails intermittently, sometimes with a "nothing to copy" warning repeated frequently in mtrace
To Reproduce
For highest probability run multiple-pause-resume.sh -r 50 on PTL with nocodec
Name of the platform(s) on which the bug is observed.
Platform: MTL, PTL
Screenshots or console output
mtrace:
[ 1250.959101] <wrn> dai_comp: dai_common_copy: comp:3 0x30005 nothing to copy, src_frames: 96, sink_frames: 0
[ 1250.960103] <wrn> dai_comp: dai_common_copy: comp:3 0x30005 nothing to copy, src_frames: 96, sink_frames: 0
[ 1250.961101] <wrn> dai_comp: dai_common_copy: comp:3 0x30005 nothing to copy, src_frames: 96, sink_frames: 0
[ 1250.962101] <wrn> dai_comp: dai_common_copy: comp:3 0x30005 nothing to copy, src_frames: 96, sink_frames: 0
[ 1250.962128] <wrn> host_comp: host_get_copy_bytes_normal: comp:2 0x20005 Skipped 20 no-bytes events in last 21 ms, bytes 0
[ 1250.962133] <wrn> host_comp: host_get_copy_bytes_normal: comp:2 0x20005 no bytes to copy, available samples: 384, free_samples: 0
Nothing obvious in the kernel log. In fact it is interesting, that "always" when this bug appears the kernel log is absent in the CI report, but manually reproducing the bug doesn't reveal obvious problems on the Linux side
changed the title [-][BUG] MTL nocodec multiple-pause-resume failures with "nothing to copy"[/-][+][BUG] multiple platforms and topologies: multiple-pause-resume failures with "nothing to copy"[/+]on Jul 16, 2025
@lyakh I think the MTLP nocodec and PTL nocodec failures should be separate issues. If you look at the errors, on MTLP, it looks like the DW DMA runs into an xrun. That cannot be the case on PTL as we dont use the DWDMA for SSP on PTL
@lyakh@kv2019i I am thinking our multiple-pause-resume test needs a bit of modification in terms on how we deal with xruns when executing the "press space for pause" specifically. A lot of errors we see look like this: === PAUSE === aplay: do_pause:1586: pause push error: File descriptor in bad state
This error when doing pause usually occurs when the stream is not in the RUNNING state.
And I think this is because when an xrun happens, the application will try to recover from the xrun with a prepare and restart and we likely do a pause when the stream is not yet in the RUNNING state after recovering from the xrun.
We probably need to modify the pause script to make sure that the stream state is correct before pausing.
Of course, if the application never recovers from the xrun, we've got to fix that. What do you think?
@lyakh@kv2019i I am thinking our multiple-pause-resume test needs a bit of modification in terms on how we deal with xruns when executing the "press space for pause" specifically. A lot of errors we see look like this: === PAUSE === aplay: do_pause:1586: pause push error: File descriptor in bad state
This error when doing pause usually occurs when the stream is not in the RUNNING state.
And I think this is because when an xrun happens, the application will try to recover from the xrun with a prepare and restart and we likely do a pause when the stream is not yet in the RUNNING state after recovering from the xrun. We probably need to modify the pause script to make sure that the stream state is correct before pausing.
Of course, if the application never recovers from the xrun, we've got to fix that. What do you think?
I ran the multiple-pause-test several times on the PTL nocodec device and it failed with the "File descriptor in bad state" error in about 40-50% of the time. With this PR, I have not seen the error in the last 5 runs on the same device. Hopefully this lets us focus on the real problem, which is why the xruns happen when the test fails.
I ran the multiple-pause-test several times on the PTL nocodec device and it failed with the "File descriptor in bad state" error in about 40-50% of the time. With this PR, I have not seen the error in the last 5 runs on the same device. Hopefully this lets us focus on the real problem, which is why the xruns happen when the test fails.
@ranj063 interesting, thanks for checking! Indeed it might be unreasonable to expect audio to be able to pause and resume with some 20ms intervals like, e.g. in https://sof-ci.01.org/sofpr/PR10122/build14047/devicetest/index.html?model=PTLH_RVP_NOCODEC&testcase=multiple-pause-resume-50 . But changing our test script lets our test pass but doesn't fix the problem? So if the user for whatever reason ends up hitting pause-resume quickly they still can get this failure. Can we instead fix it in the driver, say, to implement the same delay there?
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.
Activity
abonislawski commentedon Jul 15, 2025
@wszypelt could you please assign someone to reproduce this in python tests?
lyakh commentedon Jul 16, 2025
Now also observed in a PR test on PTL #10094 (comment) but unclear whether it is caused by that PR or not.
[-][BUG] MTL nocodec multiple-pause-resume failures with "nothing to copy"[/-][+][BUG] multiple platforms and topologies: multiple-pause-resume failures with "nothing to copy"[/+]lyakh commentedon Jul 16, 2025
now also observed on PTL in SDW and nocodec configurations without the IPC timeout https://sof-ci.01.org/sofpr/PR10118/build13953/devicetest/index.html?model=PTLP_RVP_SDW&testcase=multiple-pause-resume-50 and https://sof-ci.01.org/sofpr/PR10118/build13953/devicetest/index.html?model=PTLP_RVP_SDW&testcase=multiple-pause-resume-50
lgirdwood commentedon Jul 16, 2025
@ranj063 is your pause/release stress tester ready ?
ranj063 commentedon Jul 17, 2025
@lgirdwood nope still working on it. Hopefully by tomorrow.
lyakh commentedon Jul 22, 2025
Update: this bug is now mostly appearing on PTL. Most often in the "multiple-pause-resume" test with the nocodec topology, but sometimes also with other topologies and in pure playback or capture "pause-resume" tests as well. Some occurrences:
https://sof-ci.01.org/sofpr/PR10094/build13984/devicetest/index.html?model=PTLH_HDA_AIOC&testcase=check-pause-resume-playback-100
https://sof-ci.01.org/sofpr/PR10094/build13984/devicetest/index.html?model=PTLH_RVP_NOCODEC&testcase=multiple-pause-resume-50
https://sof-ci.01.org/sofpr/PR10122/build14047/devicetest/index.html?model=PTLH_RVP_NOCODEC&testcase=multiple-pause-resume-50
https://sof-ci.01.org/sofpr/PR10118/build13953/devicetest/index.html?model=PTLP_RVP_SDW&testcase=multiple-pause-resume-50
https://sof-ci.01.org/sofpr/PR10118/build13953/devicetest/index.html?model=PTLH_RVP_NOCODEC&testcase=multiple-pause-resume-50
https://sof-ci.01.org/sofpr/PR10106/build13845/devicetest/index.html?model=MTLP_RVP_NOCODEC&testcase=multiple-pause-resume-50
ranj063 commentedon Jul 24, 2025
@lyakh I think the MTLP nocodec and PTL nocodec failures should be separate issues. If you look at the errors, on MTLP, it looks like the DW DMA runs into an xrun. That cannot be the case on PTL as we dont use the DWDMA for SSP on PTL
ranj063 commentedon Jul 24, 2025
@lyakh @kv2019i I am thinking our multiple-pause-resume test needs a bit of modification in terms on how we deal with xruns when executing the "press space for pause" specifically. A lot of errors we see look like this:
=== PAUSE === aplay: do_pause:1586: pause push error: File descriptor in bad stateThis error when doing pause usually occurs when the stream is not in the RUNNING state.
And I think this is because when an xrun happens, the application will try to recover from the xrun with a prepare and restart and we likely do a pause when the stream is not yet in the RUNNING state after recovering from the xrun.
We probably need to modify the pause script to make sure that the stream state is correct before pausing.
Of course, if the application never recovers from the xrun, we've got to fix that. What do you think?
ranj063 commentedon Jul 24, 2025
@lyakh @kv2019i have a look at this PR thesofproject/sof-test#1287
I ran the multiple-pause-test several times on the PTL nocodec device and it failed with the "File descriptor in bad state" error in about 40-50% of the time. With this PR, I have not seen the error in the last 5 runs on the same device. Hopefully this lets us focus on the real problem, which is why the xruns happen when the test fails.
lyakh commentedon Jul 25, 2025
@ranj063 interesting, thanks for checking! Indeed it might be unreasonable to expect audio to be able to pause and resume with some 20ms intervals like, e.g. in https://sof-ci.01.org/sofpr/PR10122/build14047/devicetest/index.html?model=PTLH_RVP_NOCODEC&testcase=multiple-pause-resume-50 . But changing our test script lets our test pass but doesn't fix the problem? So if the user for whatever reason ends up hitting pause-resume quickly they still can get this failure. Can we instead fix it in the driver, say, to implement the same delay there?
lyakh commentedon Jul 25, 2025
also occurs on LNL https://sof-ci.01.org/sofpr/PR10127/build14226/devicetest/index.html?model=LNLM_RVP_NOCODEC&testcase=multiple-pause-resume-50
kv2019i commentedon Aug 5, 2025
Related sof-test PR thesofproject/sof-test#1287 to this test case.
github-actions commentedon Oct 5, 2025
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.