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] arecord fails with non-zero exit status with check-pause-resume-playback-100 #9191
changed the title [-][BUG] arecord fails with non-zero exit status[/-][+][BUG] arecord fails with non-zero exit status with check-pause-resume-playback-100[/+]on Sep 4, 2024
t=14110 ms: aplay: (29/100) Found === PAUSE === , pausing for 166 ms
t=14110 ms: aplay: ERROR: aplay: do_pause:1567: pause push error: File descriptor in bad state
The errors happen when there are no clear errors in either kernel dmesg.txt or FW mtrace.txt. There does seem to be a timing anomaly seen in the logs, like here:
Activity
app: boards: ace20_lnl: set DMA_INTEL_ADSP_HDA_TIMING_L1_EXIT=y
kv2019i commentedon Jun 5, 2024
@abonislawski @serhiy-katsyuba-intel It seems just enabling the L1_EXIT is not sufficient, record failure still seen (see comment #9194 (comment) ).
The logs don't have much, but this very much seems like a case of host DMA not moving, and arecord exiting with error as no data is received.
marc-hb commentedon Jun 7, 2024
Is thesofproject/linux#5048 a duplicate? Then maybe close this one because 5048 has a better looking description :-)
lgirdwood commentedon Jun 10, 2024
Lets keep it open for the moment, just as a place holder on the FW side for v2.10
[-][BUG] arecord fails with non-zero exit status[/-][+][BUG] arecord fails with non-zero exit status with check-pause-resume-playback-100[/+]kv2019i commentedon Sep 4, 2024
Looking at this again. Narrowing the scope of this bug to specifically cover the failure with pause-resume case with a recent occurence in:
https://sof-ci.01.org/linuxpr/PR4733/build4501/devicetest/index.html?model=LNLM_SDW_AIOC&testcase=check-pause-resume-playback-100
Failure fingerprint in sof-test console:
The errors happen when there are no clear errors in either kernel dmesg.txt or FW mtrace.txt. There does seem to be a timing anomaly seen in the logs, like here:
This is clearly larger pause in activity than the ~0.1-0.2ms delays that are used in the test case.
kv2019i commentedon Dec 13, 2024
Not seen in PR/daily tests for a week, closing.