Repository navigation
[BUG] DSP reset fails occasionally on ICL (rarer on other platorms?) #3395
Description
Describe the bug
The ICL FW boot fails occasionally. Example case here:
https://sof-ci.01.org/linuxpr/PR2413/build4423/devicetest/
The driver has had retry logic since the initial upstream version and there has been multiple patches to adjust the trace output so that error-level traces are emitted only if all FW boot attempts fail.
On ICL the first-boot failure seems to happen with fairly high reproduction rate. This could be a symptom of gaps in implementation of ICCMAX flow -> thesofproject/linux#2310 and https://github.com/thesofproject/sof/issues/1739 , but this has not been confirmed.
To Reproduce
Triggered by standard SOF CI test set
Also with this?
$ ./check-runtime-pm-status.sh -l 50Reproduction Rate
Seen regularly in CI.
Expected behavior
First boot should be successful.
Impact
No end-user impact so thus P3.
Environment
Not specific to any recent version, but for example triggers on:
Linux: 7e7294e230bb .travis.yml: fixup options, cores and clang support, bump to focal
SOF: 35d9034 build-tools.sh: fix misnamed locals DO_BUILD_topology and
ICL HDA configuration with generic topology.
Screenshots or console output
https://sof-ci.01.org/linuxpr/PR2413/build4423/devicetest/
jf-icl-rvp-hda-4 kernel: [ 611.727099] sof-audio-pci 0000:00:1f.3: periods:1
jf-icl-rvp-hda-4 kernel: [ 611.727186] sof-audio-pci 0000:00:1f.3: Attempting iteration 0 of Core En/ROM load...
jf-icl-rvp-hda-4 kernel: [ 611.727748] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0xf0f0f0f successful
jf-icl-rvp-hda-4 kernel: [ 611.727765] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0xf0f0f0e successful
jf-icl-rvp-hda-4 kernel: [ 611.727770] sof-audio-pci 0000:00:1f.3: unstall/run core: core_mask = 1
jf-icl-rvp-hda-4 kernel: [ 611.727777] sof-audio-pci 0000:00:1f.3: DSP core(s) enabled? 1 : core_mask 1
jf-icl-rvp-hda-4 kernel: [ 611.728304] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0x80000000 successful
jf-icl-rvp-hda-4 kernel: [ 611.728312] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0xf010e0e successful
jf-icl-rvp-hda-4 kernel: [ 612.028497] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0x6000010 timedout
jf-icl-rvp-hda-4 kernel: [ 612.028503] sof-audio-pci 0000:00:1f.3: unknown ROM status value 06000010
-------------> [ 612.028509] sof-audio-pci 0000:00:1f.3: status = 0x00000000 panic = 0x00000000
jf-icl-rvp-hda-4 kernel: [ 612.028522] sof-audio-pci 0000:00:1f.3: extended rom status: 0x6000010 0x0 0x0 0x0 0x0 0x0 0x2001180 0x0
jf-icl-rvp-hda-4 kernel: [ 612.028525] sof-audio-pci 0000:00:1f.3: unknown ROM status value 06000010
jf-icl-rvp-hda-4 kernel: [ 612.028530] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0x1010f0f successful
jf-icl-rvp-hda-4 kernel: [ 612.028535] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0x1000f0f successful
jf-icl-rvp-hda-4 kernel: [ 612.028537] sof-audio-pci 0000:00:1f.3: DSP core(s) enabled? 0 : core_mask f
-------------> [ 612.028539] sof-audio-pci 0000:00:1f.3: Attempting iteration 1 of Core En/ROM load...
jf-icl-rvp-hda-4 kernel: [ 612.028934] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0xf0f0f0f successful
Activity
marc-hb commentedon Sep 9, 2020
Just found thesofproject/sof-test#340 which seems like a (partial?) duplicate, @fredoh9 ?
Other related links shared by @xiulipan (thanks!)
thesofproject/linux#2382 ASoC: SOF: Intel: hda: reduce verbosity of boot error logs
thesofproject/sof-test@8797c85a6c64204 remove filter on initial boot issues
kv2019i commentedon Sep 9, 2020
Did a stress test on one ICL RVP with a loop putting system to suspend, resuming, booting the DSP, and then repeating the sequence.
Bug occurence rate: 0.6% (out of 13000 iterations)
With no system suspend inbetween, I did not see boots fail.
Test script:
marc-hb commentedon Sep 9, 2020
Thanks to @kv2019i 's indications here are some relevant pointers in the kernel source. As of version 5.8, the retry logic is located in
hda_dsp_cl_boot_firmware()insound/soc/sof/intel/hda-loader.c; this is the function logging some of the relevant messages. HDA_FW_BOOT_ATTEMPTS is currently 3https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/sof/intel/hda-loader.c?h=v5.8
TIMEOUT_DEFAULT_BOOT_MSis 2000 yet the interval betweenAttempting iteration 0andAttempting iteration 1at https://sof-ci.01.org/linuxpr/PR2413/build4423/devicetest/ is exactly 300 ms, @kv2019i ?marc-hb commentedon Sep 10, 2020
From @aiChaoSONG
The message is exactly the same (even the PCI ID) and the timeout 300ms too. Only one retry. This has been much, much rarer than on ICL.
I just added
cmlto thesofproject/sof-test#372marc-hb commentedon Sep 23, 2020
@ranj063 thinks thesofproject/linux#2434 might be related.
[-][BUG] FW boot fails occasionally on ICL [/-][+][BUG] FW boot fails occasionally on ICL(rare on other platorms)[/+][-][BUG] FW boot fails occasionally on ICL(rare on other platorms)[/-][+][BUG] DSP reset fails occasionally on ICL(rare on other platorms)[/+]xiulipan commentedon Oct 21, 2020
Update the bug title as the issue is actually DSP reset before load FW to DSP.
Also add comments about other platforms, as the issue now can be seen on most platforms but with lower rate.
kv2019i commentedon Nov 2, 2020
WIP version of ICCMAX flow implementation now available: thesofproject/linux#2548 This could potentially help with this bug.
fredoh9 commentedon Nov 2, 2020
Trying to reproducing without/with linux#2548. To test this,
sof-test 61b077beshould be reverted first, otherwise it ignores this error.fredoh9 commentedon Nov 3, 2020
I'm still able to reproduce same problem with PR#2548. Hum... I doubled checked without the PR the problem is reproduced. This is NOT 100% but when I tried this command it's high chance to see the problem.
without/with PR#2548, I'm seeing same error pattern.
With the PR, powering up C3 may be too late?
[-][BUG] DSP reset fails occasionally on ICL(rare on other platorms)[/-][+][BUG] DSP reset fails occasionally on ICL (rarer on other platorms?)[/+]plbossart commentedon Jun 10, 2021
@kv2019i @fredoh9 @marc-hb is this issue still occurring, if not can we close?
kv2019i commentedon Jun 10, 2021
I believe yes, we are hiding this with the multiple DSP boot retries. The boot-from-IMR code @keyonjie might actually help to this.
That's another question whether we want to keep a bug open.
marc-hb commentedon Jun 10, 2021
I think we could easily monitor this with a small,
[DO NOT UPSTREAM]kernel patch that prints an error after the 1st or 2nd boot retry. Maybe not right now but once the daily results get better.fredoh9 commentedon Jun 11, 2021
[DO NOT UPSTREAM]patch is up to maintainers, but I think there is no point to keep this issue OPEN as we are hiding this issue already and set P3 for this. I will close this if no one has objection in 24 hours.marc-hb commentedon Oct 25, 2021
It's back? #4873
aiChaoSONG commentedon Oct 26, 2021
@marc-hb I tried to reproduced #4873, even with the commits that spotted #4873, I failed to reproduce it.
marc-hb commentedon Dec 6, 2021
Important, November 2021 refactoring: thesofproject/linux#3250