check-kmod-load-unload: wait up to 10 seconds for firmware to boot. New function poll_wait_for().

[marc-hb]

check-kmod-load-unload: wait 10 seconds for firmware to boot

Now that the test has been just fixed in commit 71a9cca, of course
it started failing:

https://sof-ci.01.org/sofpr/PR5383/build12069/devicetest/?model=BYT_MB_NOCODEC&testcase=check-kmod-load-unload-after-playback

This proves the older version wasn't testing anything: classic case of
"green failure"
https://github.com/thesofproject/sof-test/issues?q=+label%3A%22False+Pass+%2F+green+failure%22+

Firmware does not boot instantly. We even have retries:

thesofproject/linux#3255
thesofproject/linux@2a3c9269474c

So, poll journalctl for a maximum of 10 seconds before failing.

---

lib.sh: add new poll_wait_for() function

This will immediately be used for waiting until the firmware is loaded
but is generic and will be useful in other places.

[marc-hb]

suspend/resume timeout in https://sof-ci.01.org/softestpr/PR862/build983/devicetest/?model=APL_UP2_NOCODEC_ZEPHYR&testcase=check-suspend-resume-with-capture-5, everything else is green

Logs of the modified tests look as expected.

[marc-hb]

@plbossart , @ujfalusi , what is the maximum time we should wait between modprobe completion and 'firmware boot complete' message?

[plbossart]

@plbossart , @ujfalusi , what is the maximum time we should wait between modprobe completion and 'firmware boot complete' message?

modprobe completion means we will execute the driver probe, but for SOF it's handled in a workqueue. In addition we will do a request_module() for HDaudio stuff, and i915 IIRC, so in theory it could take a while. I think in those cases it's not uncommon to wait 60s.

The firmware download itself should not take longer than 500ms, even with the worst sand-bagging in the world and retries.

[marc-hb]

so in theory it could take a while. I think in those cases it's not uncommon to wait 60s.

60s?!? Wow! Is that only in pathological cases like this i915 timeout:

• [BUG]ADLP firmware boot delayed by i915 issue (failure in check-sof-logger) linux#3042

... or do you have "regular" cases in mind too? I would return to the vendor a computer that forces me to wait 1minute after resume before using audio.

I'm reluctant to have a long timeout by default because on the systems we test right now it usually takes less than 1 second and if it starts taking much longer for the exact same configurations then I think we should be made aware. Then we could always extend on a per-product basis.

[plbossart]

@marc-hb 60s is just one way of expressing a dependency on things that take time - but we don't know how much.

Make that 10-15s for test scripts and that should be good enough

[marc-hb]

timeout changed to 10s

[marc-hb]

SOFCI TEST

[marc-hb]

https://sof-ci.01.org/softestpr/PR862/build985/devicetest/?model=APL_UP2_NOCODEC_ZEPHYR&testcase=multiple-pipeline-all looks like

• [BUG] IPC timed out when multiple-pipeline on APL_UP2_NOCODEC_ZEPHYR sof#4414

https://sof-ci.01.org/softestpr/PR862/build985/devicetest/?model=WHL_UPEXT_HDA_ZEPHYR&testcase=check-suspend-resume-with-playback-5 looks like a variation of

• [BUG] [ZEPHYR] sof-logger dead: Invalid filename length 1650680879 or ldc file does not match firmware sof#5352

A couple unrelated TIMEOUT, the rest is PASS

[aiChaoSONG]

if the user use it wrong, maybe we should inform the correct usage?

[marc-hb]

We could but this function is not meant to be used outside sof-test, so the only user using it wrong is either you or me.

More seriously, the only user using it wrong is someone writing sof-test code who can just open the file and look at the header above = what they should have done already before even starting to use the function.