-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
check-sof-logger.sh: fix no-log-file failures due to runtime Power Management #1109
check-sof-logger.sh: fix no-log-file failures due to runtime Power Management #1109
Conversation
The logger test case has a design limitation in that it assumes the SOF DSP to remain powered up between driver reload and start of the logger. This creates a possibility for a race with runtime PM (RPM). If the DSP goes to runtime suspend during this window, it is not guaranteed that the SOF driver will provide any logs. Some logging mechanisms save the logs that were emitted before suspend (sof-logger/IPC3), but some not (cavstool/IPC3 and mtrace/IPC4). To limit the window , add a simple ping of all PCM nodes just before logger process is started. This is a crude mechanism but something that works with all variants of SOF. End result is that DSP will be resumed to D0 just before the logger test starts. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Only system-PM errors in https://sof-ci.01.org/softestpr/PR1109/build763/devicetest/index.html , https://sof-ci.01.org/softestpr/PR1109/build762/devicetest/index.html and https://sof-ci.01.org/softestpr/PR1109/build761/devicetest/index.html . And no cases of empty mtrace. |
We don't run check-sof-logger in PR testing (like https://sof-ci.01.org/softestpr/PR1109/build761/devicetest/index.html), we never have - cause it was failing all the time. We only ever ran it in daily tests. @fredoh9 could you add them to the PR test plan? Then we can SOFCI TEST this and merge. |
I added check-sof-logger.sh to mtl pr test. And I manually ran check-sof-logger.sh with this PR on MTLP_RVP_HDA, it still failed. But I ran the test automatically thre result looks good. |
SOFCI TEST |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I re-test again after re-deploying daily build. Now constantly PASS. I did not deploy daily build before, probably the build installed wasn't stable. There is no way I can track the build installed before.
Looks good!
MTLP_RVP_HDA failed in PR test. Interestingly I tried on MTLP_RVP_HDA when I saw the failure with this PR. Apparently the result get better but not complete solution. |
@fredoh9 I think this is a different problem:
I checked the DUT and there's the 60sec timeout due to missing i915 driver, and there's a non-SOF driver registered as card0, so the test case logic goes wrong. We can try to make the test case logic more robust, but I think this is a different problem. |
The check for DSP boot assumes SOF is always card0 in the system, and this leads to failure. Fix the issue by using the existing sof_firmware_boot_complete() check to wait for DSP boot to successfully complete. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Ok, @fredoh9 , added a second patch to this PR to fix the issue that affects this specific DUT. The check should now pass even if some non-SOF ALSA driver is loaded as card0 (like is the case on this DUT). |
Thank you a lot! I will check again in this afternoon! |
Interesting, do we have another race?
|
I tried on MTLP_RVP_HDA,
And trigger sof-logger test plan also, Similar errors found. |
lib.sh:sof_firmware_boot_complete() ensures DSP has booted, but it does not guarantee SOF driver probe has completed. So it is still possible some of the interfaces SOF driver exposes to user-space are not available (including interfaces needed to run loggers). Tracing is initialized before ALSA card registration in SOF diver (see snd_sof_device_probe() in SOF driver), so by waiting for ALSA card to show up in procfs, we can guarantee tracing related interfaces have been initialized. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
check-sof-logger now all passed in https://sof-ci.01.org/softestpr/PR1109/build772/devicetest/index.html . By chance or design? |
SOFCI TEST |
I re-ran sof-logger test, all passed! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very clean code, easy to fix later if needed. Will hopefully help with current PRs, merging.
|
||
wait_for_sof_alsa_card() | ||
{ | ||
if poll_wait_for 1 "$MAX_WAIT_FW_LOADING" sof_alsa_card_found ; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In a follow-up PR please:
if poll_wait_for 1 "$MAX_WAIT_FW_LOADING" sof_alsa_card_found ; then | |
if poll_wait_for 1 "$1" sof_alsa_card_found ; then |
mtrace still empty in 2 out of 6 devices in today's daily test run 32787
The |
The logger test case has a design limitation in that it assumes the SOF DSP to remain powered up between driver reload and start of the logger. This creates a possibility for a race with runtime PM (RPM).
If the DSP goes to runtime suspend during this window, it is not guaranteed that the SOF driver will provide any logs. Some logging mechanisms save the logs that were emitted before suspend (sof-logger/IPC3), but some not (cavstool/IPC3 and mtrace/IPC4).
To limit the window , add a simple ping of all PCM nodes just before logger process is started. This is a crude mechanism but something that works with all variants of SOF. End result is that DSP will be resumed to D0 just before the logger test starts.