Skip to content

[BUG] multiple platforms and topologies: multiple-pause-resume failures with "nothing to copy" #10116

Closed as not planned

Description

@lyakh

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

Reproduction Rate
about 20%

Impact
Potential bug in firmware or the driver

Environment

  1. Appeared in multiple PR tests, e.g. https://sof-ci.01.org/sofpr/PR10106/build13845/devicetest/index.html?model=MTLP_RVP_NOCODEC&testcase=multiple-pause-resume-50 but has also been reproduced with a clean state:
    • Kernel: 0aa367fe53d5
    • SOF: b35aba3
    • Zephyr: e22ca6b132840efb23b4a00ff7718225a0dd9f29
  2. Name of the topology file
    • Topology: sof-mtl-nocodec.tplg, sof-ptl-nocodec.tplg
  3. 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

Activity

  1. added
    bugSomething isn't working as expected
    on Jul 14, 2025
  2. abonislawski commented on Jul 15, 2025

    @abonislawski
    Member

    @wszypelt could you please assign someone to reproduce this in python tests?

  3. lyakh commented on Jul 16, 2025

    @lyakh
    CollaboratorAuthor

    Now also observed in a PR test on PTL #10094 (comment) but unclear whether it is caused by that PR or not.

  4. 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
  5. lgirdwood commented on Jul 16, 2025

    @lgirdwood
    Member

    @ranj063 is your pause/release stress tester ready ?

  6. ranj063 commented on Jul 17, 2025

    @ranj063
    Collaborator

    @ranj063 is your pause/release stress tester ready ?

    @lgirdwood nope still working on it. Hopefully by tomorrow.

  7. ranj063 commented on Jul 24, 2025

    @ranj063
    Collaborator

    @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

  8. ranj063 commented on Jul 24, 2025

    @ranj063
    Collaborator

    @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?

  9. ranj063 commented on Jul 24, 2025

    @ranj063
    Collaborator

    @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 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.

  10. lyakh commented on Jul 25, 2025

    @lyakh
    CollaboratorAuthor

    @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.

    @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?

  11. kv2019i commented on Aug 5, 2025

    @kv2019i
    Collaborator

    Related sof-test PR thesofproject/sof-test#1287 to this test case.

  12. github-actions commented on Oct 5, 2025

    @github-actions

    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.

  13. added
    staleIssue/PR marked as stale and will be closed after 14 days if there is no activity.
    on Oct 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

P3Low-impact bugs or featuresbugSomething isn't working as expectedstaleIssue/PR marked as stale and will be closed after 14 days if there is no activity.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions