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
ADL - N : Resume failures with IPC causing suspend failures in stress tests #6475
The suspend is done with error on CTX_SAVE (as DSP in unresponsive), and there are further errors on next resume.
In the other log (kernel_log_20221017.txt), SOF dynamic debug log are not enabled, so there is less to see, but the first error is reported on resume. So this looks a bit different.
So far nothing wrong spotted in the kernel side logs (e.g. an invalid sequence).
Only similar bug (searched open and clossed, kernel + fw) is this one: #6185 .. but this happens with playback (so different direction) and a different use-case (multiple-pipeline-playback).
Given the kernel side flow looks ok, moving to firmware side.
@lgirdwood We dont have a clear reproduction scenario. FW trace wont help with suspend resume right ? ( since FW trace starts after DSP starts) - but will try how we can get it.
@lgirdwood We dont have a clear reproduction scenario. FW trace wont help with suspend resume right ? ( since FW trace starts after DSP starts) - but will try how we can get it.
Sorry, I mean we need the log from part 1 - the resume that fails.
0000:00:1f.3: ipc tx error for 0x30030000 (msg/reply size: 16/12): -22
0000:00:1f.3: sof_ipc3_route_setup: route DMIC1.IN -> BUF11.0 failed
0000:00:1f.3: sof_ipc3_set_up_all_pipelines: route set up failed
0000:00:1f.3: Failed to restore pipeline after resume -22
0000:00:1f.3: PM: pci_pm_resume+0x0/0xef returned -22 after 114680 usecs
0000:00:1f.3: PM: failed to resume async: error -22
This may shed some light on the previous suspend (where we may not have shutdown cleanly).
@sathyap-chrome Would be good to have more samples of failing case logs. It would be curious to see if the problem is always:
TRIG_STOP fail on DMIC before suspend (ADSP hw potentially in undefined state)
suspend (ADSP powered off but not cleanly as we have CTX_SAVE error, hw potentially in undefined state)
resume
error in setting up path for dmic
The HW power-cycling should of course help, but we've had cases in the past where e.g. the DMA hw has had issues that cannot be recovered by the above flow. The rootcause would then be the TRIG_STOP on DMIC.
I was now able to reproduce once locally on a "Nereid" device. FYI @abonislawski as you have the same hw.
No FW logs yet, but below are kernel logs showing the IPC sequence of a working and non-working case. Reproduction is once per day for me now, so will spend some time looking at the logs and then planning what to try next. But FYI with others who have same hw, it is possible to trigger this bug with this setup.
The sequence of IPC messages kernel sends seems valid. Here the failure is not with DMIC, but rather the first IPC sent to tear down the DSP pipelines for suspend (COMP_FREE for SSP1.IN). E.g. this line pair (not the timestamp showing 2sec, first line is last message to set up the DSP, second is start of suspend):
Activity
kv2019i commentedon Oct 24, 2022
Note on kernel version:
kv2019i commentedon Oct 24, 2022
The failures seem to be IPC timeouts with no reported DSP crash.
In the first log (pipeline_ipc_fail.txt) the first error is timeout on TRIG_STOP for DMIC pipeline:
The suspend is done with error on CTX_SAVE (as DSP in unresponsive), and there are further errors on next resume.
In the other log (kernel_log_20221017.txt), SOF dynamic debug log are not enabled, so there is less to see, but the first error is reported on resume. So this looks a bit different.
So far nothing wrong spotted in the kernel side logs (e.g. an invalid sequence).
kv2019i commentedon Oct 24, 2022
Only similar bug (searched open and clossed, kernel + fw) is this one: #6185 .. but this happens with playback (so different direction) and a different use-case (multiple-pipeline-playback).
Given the kernel side flow looks ok, moving to firmware side.
lgirdwood commentedon Oct 24, 2022
@sathyap-chrome do you have the FW log ? I would say we are broken at the resume time if we cant hookup a route to DMIC.
lgirdwood commentedon Oct 24, 2022
@mwasko fyi - pls assign.
sathyap-chrome commentedon Oct 25, 2022
@lgirdwood We dont have a clear reproduction scenario. FW trace wont help with suspend resume right ? ( since FW trace starts after DSP starts) - but will try how we can get it.
lgirdwood commentedon Oct 25, 2022
Sorry, I mean we need the log from part 1 - the resume that fails.
This may shed some light on the previous suspend (where we may not have shutdown cleanly).
kv2019i commentedon Oct 26, 2022
@sathyap-chrome Would be good to have more samples of failing case logs. It would be curious to see if the problem is always:
The HW power-cycling should of course help, but we've had cases in the past where e.g. the DMA hw has had issues that cannot be recovered by the above flow. The rootcause would then be the TRIG_STOP on DMIC.
kv2019i commentedon Oct 26, 2022
I was now able to reproduce once locally on a "Nereid" device. FYI @abonislawski as you have the same hw.
No FW logs yet, but below are kernel logs showing the IPC sequence of a working and non-working case. Reproduction is once per day for me now, so will spend some time looking at the logs and then planning what to try next. But FYI with others who have same hw, it is possible to trigger this bug with this setup.
The sequence of IPC messages kernel sends seems valid. Here the failure is not with DMIC, but rather the first IPC sent to tear down the DSP pipelines for suspend (COMP_FREE for SSP1.IN). E.g. this line pair (not the timestamp showing 2sec, first line is last message to set up the DSP, second is start of suspend):
FAIL case
OK case:
40 remaining items
ASoC: SOF: ipc3-topology: use old pipeline teardown flow with SOF2.1 …
ASoC: SOF: ipc3-topology: use old pipeline teardown flow with SOF2.1 …
BACKPORT: FROMGIT: ASoC: SOF: ipc3-topology: use old pipeline teardow…
BACKPORT: ASoC: SOF: ipc3-topology: use old pipeline teardown flow wi…
BACKPORT: FROMGIT: ASoC: SOF: ipc3-topology: use old pipeline teardow…
BACKPORT: ASoC: SOF: ipc3-topology: use old pipeline teardown flow wi…
BACKPORT: ASoC: SOF: ipc3-topology: use old pipeline teardown flow wi…
BACKPORT: ASoC: SOF: ipc3-topology: use old pipeline teardown flow wi…
ASoC: SOF: ipc3-topology: use old pipeline teardown flow with SOF2.1 …
FROMGIT: ASoC: SOF: ipc3-topology: use old pipeline teardown flow wit…
BACKPORT: ASoC: SOF: ipc3-topology: use old pipeline teardown flow wi…
BACKPORT: ASoC: SOF: ipc3-topology: use old pipeline teardown flow wi…
BACKPORT: FROMGIT: ASoC: SOF: ipc3-topology: use old pipeline teardow…
FROMGIT: ASoC: SOF: ipc3-topology: use old pipeline teardown flow wit…
FROMGIT: ASoC: SOF: ipc3-topology: use old pipeline teardown flow wit…