check-suspend-resume: add new -u option to test without audio

[marc-hb]

This should help identifying suspend/resume issues unrelated to audio

2 commits must be reviewed separately

[marc-hb]

Unrelated snap / SELinux issue on https://sof-ci.01.org/softestpr/PR918/build49/devicetest/?model=TGLU_UP_HDA_ZEPHYR&testcase=verify-kernel-boot-log, working on it. everything else green.

Jun 13 17:06:56 sh-tglu-up-hda-04 snapd-desktop-integration.snapd-desktop-integration[1419]: cmd_run.go:1044: WARNING: cannot create user data directory: failed to verify SELinux context of /home/ubuntu/snap: exec: "matchpathcon": executable file not found in $PATH

EDIT: fixed by removing all snaps

[plbossart]

should there be a checkpoint here before reloading audio drivers?

[marc-hb]

There could be but it's not really necessary because one of the last thing sleep_once did is to check the kernel logs and die if that failed. So if the execution makes it to this point it means the kernel logs are free of errors so far.

[plbossart]

I don't disagree, it's more that if you get an error while loading audio drivers it might be a bit difficult to check if the test worked until the point where you start loading driver. You'd get a fail and no intermediate information, that's it.

[marc-hb]

You will see the difference because of the different die error message; one is dump_and_die "Caught error in kernel log" whereas the other one below is die "Found kernel error after reloading audio drivers"

Setting the $KERNEL_CHECKPOINT is completely quiet so it won't help in that respect.

[marc-hb]

Think of $KERNEL_CHECKPOINT as a way to avoid errors from previous tests but inside the same test looking for errors and dying is actually a "stronger" checkpoint.

[plbossart]

I will have to trust you on that, I don't have any context here.

[plbossart]

LGTM

[marc-hb]

There is another, theoretical problem with $KERNEL_CHECKPOINT: it's not "atomic". In other words, kernel errors happening between sof-kernel-log-check.sh $KERNEL_CHECKPOINT and $KERNEL_CHECKPOINT=now are theoretically missed! This is not a real problem in practice because:

• we usually do nothing in that window
• we "cheat" and actually check KERNEL_CHECKPOINT - N seconds behind the scenes! Ugly workaround.

But still, journalctl performance issues and other exceptions aside I think we should generally set KERNEL_CHECKPOINT only once at the start of a test to be really sure not to miss any error.

@aiChaoSONG , @fredoh9 thoughts?