Closed keqiaozhang closed 1 year ago
@keqiaozhang @XiaoyunWu6666 are you sure the script is working? This is supposed to be a test WITHOUT any audio driver, but here we can see clearly references to sof-audio-pci-intel-tgl?
This was in daily test run 13499
I noticed that all kmod-load-unload
tests failed in the same run[*], so we should probably start there first!
[*] because of
Indeed this seems to be a case of compounded issues. I wonder why an IPC with the DMA trace configuration is not fatal, we seem to continue to probe - not sure how this works. Adding @ujfalusi for comments.
From the log for: https://sof-ci.sh.intel.com/#/result/planresultdetail/13499?model=ADLP_GMB_I2S_ZEPHYR&testcase=check-kmod-load-unload-after-playback-5
After module load the DSP is booted, firmware is downloaded, we receive the FW_READY message and the first IPC (GLB_TRACE_MSG:DMA_PARAMS_EXT) times out. Since a timeout is a 'feature' not a failure we continue (dtrace is not going to work since it is not initialized). The next IPC (GLB_TPLG_MSG:PIPE_NEW) also times out and that is going to fail the card creation.
I'm not sure what log the slogger contains, but it does not match the dmesg (not ecen with the previous boot, module removal). The signature looks similar to https://github.com/thesofproject/sof/issues/5733, which is closed, so there is a good chance that this issue is also?
@plbossart, @marc-hb, the
[ 359.860161] kernel: max98390 i2c-MX98390:00: ret=-108, Failed to read: 0x24FF
[ 359.864846] kernel: max98390 i2c-MX98390:01: ret=-108, Failed to read: 0x24FF
...
[ 360.046566] kernel: snd_sof:snd_sof_load_firmware_raw: sof-audio-pci-intel-tgl 0000:00:1f.3: request_firmware intel/sof/community/sof-adl.ri successful
It is really in driver loading time:
[ 359.860030] kernel: i2c_transfer+0x7f/0x100
[ 359.860033] kernel: regmap_i2c_read+0x69/0xa0 [regmap_i2c]
[ 359.860039] kernel: _regmap_raw_read+0x120/0x2b0
[ 359.860043] kernel: _regmap_bus_read+0x41/0x70
[ 359.860046] kernel: _regmap_read+0x5c/0x160
[ 359.860049] kernel: regmap_read+0x3e/0x70
[ 359.860051] kernel: max98390_i2c_probe.cold+0x179/0x1d0 [snd_soc_max98390]
[ 359.860056] kernel: i2c_device_probe+0x132/0x350
[ 359.860059] kernel: really_probe+0x17d/0x360
is printed after the suspend/resume iterations w/o audio modules and it is coming when the audio modules are re-loaded at the end of the test case.
@fredoh9 we haven't seen such issue in CI for months. Please @fredoh9 help to confirm it in recent stable-v2.2 tests.
ADLP_GMB_I2S*
is not part of stable-v2.2 nor ADLP_GMB_I2S*
are actively being tested. Hard to tell
@sathyap-chrome Can you please ask Maxim engineer to check if there is some regression for max98390 codec in upstream?
Sure @mengdonglin
This is a very old bug and no similar issue reported when testing with latest sof-dev branch. Closing this bug.
Describe the bug A clear and concise description of what the bug is. What have you tried to diagnose or workaround this issue? Please also read https://thesofproject.github.io/latest/contribute/process/bug-tracking.html for further information on submitting bugs.
To Reproduce TPLG=/lib/firmware/intel/sof-tplg/sof-adl-max98390-rt5682.tplg MODEL=ADLP_GMB_I2S_ZEPHYR ~/sof-test/test-case/check-suspend-resume.sh -l 20 -u
Reproduction Rate 1/20
Impact codec driver failed to load
Environment 1) Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver). Kernel Branch: topic/sof-dev/ 076a5996b923 SOF Branch: main/95d6499ad6b4 *Zephyr Commit: 05ec01615712 2) Name of the topology file
Screenshots or console output
dmesg