Repository navigation
[BUG] CHT suspend resume causes bogus firmware oops #1906
Description
Describe the bug
Firmware fails to both stay stable after a resume and crash properly. On cml-drop-007 this causes a kernel panic due to the fact that the driver does not detect the bogus panic and ends up reading unavailable memory.
To Reproduce
Suspend then resume a device, then attempt playback
Reproduction Rate
everytime
Expected behavior
audio would continue working after suspend resume
Impact
showstopper
Environment
- Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
- Name of the topology file
- Topology: sof-cht-max98090.tplg
- Name of the platform(s) on which the bug is observed.
- Platform: Cherrytrail
Screenshots or console output
[ 50.200024] PM: suspend exit
...
[ 65.366575] sof-audio-acpi 808622A8:00: pcm: open stream 0 dir 0
[ 65.366584] sof-audio-acpi 808622A8:00: period min 192 max 16384 bytes
[ 65.366589] sof-audio-acpi 808622A8:00: period count 2 max 16
[ 65.366592] sof-audio-acpi 808622A8:00: buffer max 65536 bytes
[ 65.367286] sof-audio-acpi 808622A8:00: rate_min: 48000 rate_max: 48000
[ 65.367292] sof-audio-acpi 808622A8:00: channels_min: 2 channels_max: 2
[ 65.369016] sof-audio-acpi 808622A8:00: rate_min: 48000 rate_max: 48000
[ 65.369022] sof-audio-acpi 808622A8:00: channels_min: 2 channels_max: 2
[ 65.369302] sof-audio-acpi 808622A8:00: rate_min: 48000 rate_max: 48000
[ 65.369306] sof-audio-acpi 808622A8:00: channels_min: 2 channels_max: 2
[ 65.369314] sof-audio-acpi 808622A8:00: pcm: hw params stream 0 dir 0
[ 65.369320] sof-audio-acpi 808622A8:00: generating page table for 00000000a5267d66 size 0xffc0 pages 16
[ 65.369325] sof-audio-acpi 808622A8:00: stream_tag 0
[ 65.369334] sof-audio-acpi 808622A8:00: ipc tx: 0x60010000
[ 65.877054] sof-audio-acpi 808622A8:00: error: ipc timed out for 0x60010000 size 108
[ 65.877110] sof-audio-acpi 808622A8:00: invalid header size 0x11a0cb4. FW oops is bogus
[ 65.877121] sof-audio-acpi 808622A8:00: error: unexpected fault 0x00000000 trace 0x00000000
[ 65.877133] sof-audio-acpi 808622A8:00: error: ipc host -> DSP: pending no complete no raw 0x00000000
[ 65.877144] sof-audio-acpi 808622A8:00: error: mask host: pending no complete no raw 0x00000000
[ 65.877152] sof-audio-acpi 808622A8:00: error: ipc DSP -> host: pending no complete no raw 0x00000000
[ 65.877160] sof-audio-acpi 808622A8:00: error: mask DSP: pending no complete no raw 0x00000000
[ 65.877168] sof-audio-acpi 808622A8:00: error: waking up any trace sleepers
[ 65.877177] sof-audio-acpi 808622A8:00: error: hw params ipc failed for stream 0
[ 65.877188] sof-audio-acpi 808622A8:00: ASoC: 808622A8:00 hw params failed: -110
[ 65.877197] Low Latency: ASoC: hw_params FE failed -110
[ 65.877741] sof-audio-acpi 808622A8:00: pcm: free stream 0 dir 0
[ 65.877968] sof-audio-acpi 808622A8:00: pcm: close stream 0 dir 0
sof-logger produces no output after the crash
Activity
cujomalainey commentedon Oct 3, 2019
It looks like the topology is simply not being pushed to the DSP after the suspend/resume cycle (assuming it is not saved in ram). This is based on the observing the ipc patterns in glk vs cht. Therefore the hw_params message is causing some indeterminate behaviour as a result which likely suggests we are missing a check somewhere in the firmware for when objects are missing. Also we should probably be pushing the topology...
ranj063 commentedon Oct 3, 2019
@cujomalainey BYT/CHT do not support suspend/resume. If you look into pcm_probe() we deliberately hold the ref_count so as to prevent the device from runtime suspending.
cujomalainey commentedon Oct 3, 2019
@ranj063 thanks for the clarification, so they should be able to preserve their topology through a suspend resume cycle?
ranj063 commentedon Oct 3, 2019
@cujomalainey no topology will be lost if the audio power domain is powered off during system suspend. Basically the SOF driver does not power off the DSP on ACPI platforms and so when the system resumes, it does not set up the topology either.
plbossart commentedon Oct 4, 2019
cujomalainey commentedon Oct 4, 2019
@ranj063 and I got suspend/resume working on cht in a semi hacky fashion. I have both a cht and byt device at my desk that we can use to get this implemented. We will continue Monday and hopefully get this working and submitted.
tlauda commentedon Mar 12, 2020
@cujomalainey It's still a problem or working now?
cujomalainey commentedon Mar 12, 2020
@tlauda yes this is still a bug as this is fixed by this PR #1523
which has not merged yet
tlauda commentedon Mar 13, 2020
@cujomalainey Since the fix is done on the kernel side I'm not sure whether this bug should be here. As I understand we can't do anything about it on firmware side?
cujomalainey commentedon Mar 14, 2020
Agreed, this was filed before the fix, I can file a new bug and cross link it if you want so the dashboard can be cleaned up.
tlauda commentedon Mar 18, 2020
@cujomalainey That would be nice.
cujomalainey commentedon Mar 18, 2020
actually apparently github has a transfer feature now
plbossart commentedon Mar 18, 2020
Sorry @cujomalainey @ranj063 it's hard to figure out what the ask is for such an old issue.
Is this to complete suspend/resume support on CHT?
cujomalainey commentedon Mar 18, 2020
yes, this is the associated bug that was originally for the CHT pm
cujomalainey commentedon Jun 4, 2020
This should have been fixed by #2138