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
SOF probe fails to invalid HDA codec mask of 0x7 #1367
An issue has been detected both by data gathered by @wenqingfu from WW42-43 CI failures, and from manual test round of #1155 by validation team (@ClarexZhou) where following kernel signature is found in dmesg:
This is a fatal problem for current driver. When the non-existant codec is probed, the action will fail and whole driver probe will be aborted. In known configurations, mask should be 0x5, with addresses #0 and #2 populated.
When this occurs, following happens:
[ 5.480386 < 0.409756>] sof-audio-pci 0000:00:1f.3: error: codec #1 probe error, ret: -5
[ 5.480390 < 0.000004>] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power off
[ 5.480561 < 0.000171>] sof-audio-pci 0000:00:1f.3: error: no matching ASoC machine driver found - aborting probe
[ 5.480564 < 0.000003>] sof-audio-pci 0000:00:1f.3: error: failed to get machine info -19
[ 5.480565 < 0.000001>] sof-audio-pci 0000:00:1f.3: error: sof_probe_work failed err: -19
@kv2019i just wondering if the codec probe fails because it doesnt exist, can we not ignore the failure and continue with the rest?
Or is the problem that the codec mask is wrong in the first place?
@ranj063 Was thinking the same that we probably should make the driver robust against this case, so it doesn't fail if a codec that is not required by the topology, fails on probe. OTOH, I think we should also try to figure out why a non-existent codec is reported (so in that sense it's good this fails now, so we get a clear indication from CI logs when this happens).
@plbossart yes, agree with @ranj063 , this still pops up in CI like the case above. I haven't yet had time to look at this, but let's definitely keep this open.
Activity
ranj063 commentedon Oct 24, 2019
@kv2019i just wondering if the codec probe fails because it doesnt exist, can we not ignore the failure and continue with the rest?
Or is the problem that the codec mask is wrong in the first place?
kv2019i commentedon Oct 24, 2019
@ranj063 Was thinking the same that we probably should make the driver robust against this case, so it doesn't fail if a codec that is not required by the topology, fails on probe. OTOH, I think we should also try to figure out why a non-existent codec is reported (so in that sense it's good this fails now, so we get a clear indication from CI logs when this happens).
plbossart commentedon Oct 24, 2019
i think we should first figure out why this mask is incorrect. IIRC each field this is linked to the SDI address
plbossart commentedon Nov 13, 2019
@kv2019i does this problem still exist?
ranj063 commentedon Nov 13, 2019
@plbossart I think it does. it showed up on one of the CI test results today on my PR but disappeared after I re-ran the test
ranj063 commentedon Nov 14, 2019
@kv2019i I am seeing this again today https://sof-ci.01.org/linuxpr/PR1481/build2449/devicetest/ICL_RVP_HDA/verify-sof-firmware-load.sh/dmesg.txt
kv2019i commentedon Nov 14, 2019
@plbossart yes, agree with @ranj063 , this still pops up in CI like the case above. I haven't yet had time to look at this, but let's definitely keep this open.