Repository navigation
check-alsabat-headset-playback.sh frequency failures found on BYT_MB_NOCODEC, others. #3438
Description
2020-09-19 UPDATE: transferred from sof-test. The logger error discussed below is a distraction tentatively fixed by thesofproject/sof-test#386, please ignore it (but do help review its 386 fix)
https://sof-ci.01.org/linuxpr/PR2452/build4513/devicetest/
check-alsabat-headset-playback.sh for BYT_MB_NOCODEC
BAT analysis: signal has 65536 frames at 44100 Hz, 1 channels, 2 bytes per sample.
Channel 1 - Checking for target frequency 997.00 Hz
Amplitude: 17958.7; Percentage: [54]
Detected peak at 988.51 Hz of 20.67 dB
Total 20.7 dB from 988.51 to 988.51 Hz
Detected peak at 997.26 Hz of 36.36 dB
Total 41.7 dB from 990.53 to 1002.64 Hz
PASS: Peak detected at target frequency
Detected peak at 1003.99 Hz of 20.69 dB
Total 41.8 dB from 1003.99 to 1003.99 Hz
Detected peak at 1006.00 Hz of 20.30 dB
Total 41.8 dB from 1006.00 to 1006.00 Hz
Detected at least 4 signal(s) in total
Return value is -1003
2020-09-18 16:50:01 UTC [REMOTE_ERROR] Starting func_exit_handler(), exit status=1, FUNCNAME stack:
2020-09-18 16:50:01 UTC [REMOTE_ERROR] main() @ /home/ubuntu/sof-test/test-case/check-alsabat.sh
2020-09-18 16:50:02 UTC [REMOTE_INFO] Starting /usr/bin/sof-logger -l /etc/sof/sof-byt.ldc -o /home/ubuntu/sof-test/logs/check-alsabat/2020-09-18-16:49:54-26390/etrace.txt
error: in logger_read(), fread(..., /sys/kernel/debug/sof/etrace) failed: Inappropriate ioctl for device(25)
alsa-utils version 1.2.2
@fredoh9 @aiChaoSONG @marc-hb does this ring a bell?
Activity
marc-hb commentedon Sep 18, 2020
The error message and failed result are brand new because I've been busy "hardening" logger-related things per your request in thesofproject/sof-test#297 (and thesofproject/sof-test#298 )
Any logger issue / "green failure" could be much, much older - we just don't know.
marc-hb commentedon Sep 18, 2020
Spending a bit more time looking at the logs, this test did NOT fail because the logger failed. It failed because alsabat returned -1003 (which may have caused the logger to fail)
So this looks like an sof bug, not an sof-test bug. Don't blame the test / the messenger :-)
I just spotted the "transfer issue" button on the right side and I tried it on some other totally unrelated issue, moving it the other way round from sof to sof-test. The transfer seemed to just work.
PS: even the logger is part of the sof repo and not in the sof-test repo.
plbossart commentedon Sep 18, 2020
Why should this:
have anything to do with alsabat errors?
marc-hb commentedon Sep 18, 2020
It all depends why alsabat failed in the first place, do we have any idea about that yet?
Why would tracing keep humming when something unexpected and unknown failed in the system? It may or it may not. It's not exactly like tracing has been stress-tested and "hardened" to handle any bad situation gracefully. As you noted yourself in thesofproject/sof-test#297 we lost it on some platforms for a couple months yet no one noticed, this gives a good indication of how much TLC tracing gets. Unless something has been designed to be fault-tolerant it's rarely ever useful to look at errors past the first one.
BTW I get a similar error (in the same place, different errno) when I start check_playback.sh but forget to define the TPLG topology (which means the test doesn't really start). This shows IMHO this logger error isn't very dramatic and again that doesn't seem to be why the test returned a FAIL.
plbossart commentedon Sep 18, 2020
alsa-bat looks at data recorded from a PCM device, and compares it with what it played.
There is no dependency at all on sof-logger.
In fact, alsa-bat doesn't know what sof-logger is, it would work with a USB card as well.
I maintain that the sof-logger error is not related to alsa-bat. Maybe it's not an sof-test issue and an SOF one, I don't know. But it's clearly not alsa-bat's fault.
fredoh9 commentedon Sep 18, 2020
For nocodec mode, pcm loopback is enabled by quirk. In this mode, in case loopback to usb card shows vert sensitive but loopback in nocodec shows less sensitive(in fact this is ideal closed loop).
I checked output wavefile, frequence response is a bit different.(first one is failure case, you can tell by filename) I checked failure rate on nocodec device, it is very low.(it should). I saw latest DEVICE_TEST result is PASS. This is not device problem, most of case same device returns PASS. Not sure what is contributing the frequency difference time to time.
This is alsabat test failure for a week, the failures are found in across the platforms.
alsabat-tests-failures-2020-09-19.xlsx
marc-hb commentedon Sep 19, 2020
Another instance of the alsabat failure on BYT_MB_NOCODEC
https://sof-ci.01.org/sofpr/PR3436/build7232/devicetest/
Any idea why we saw it only on BYT_MB_NOCODEC in sofpr?
I'm not saying it is. I'm saying they could both fail for a common reason that we don't know yet.
hijack.sh: don't start a second logger in the exit handler
marc-hb commentedon Sep 19, 2020
Spent more time on this and itlooks like we were both correct:
Fixed in thesofproject/sof-test#386, please review. "Unfortunately" alsabat didn't fail in thesofproject/sof-test#386 (?!) so we can't do a full before/after comparison but I reproduced this issue locally, see commit message.
Considering the large amount of valuable information about the alsabat failure, especially from Fred, I'm renaming this issue and transferring it to sof. Any sof-test question let's talk in thesofproject/sof-test#386 instead.
[-]sof-logger issue w/ check-alsabat-headset-playback.sh for BYT_MB_NOCODEC[/-][+]check-alsabat-headset-playback.sh failures found on BYT_MB_NOCODEC, others.[/+][-]check-alsabat-headset-playback.sh failures found on BYT_MB_NOCODEC, others.[/-][+]check-alsabat-headset-playback.sh frequency failures found on BYT_MB_NOCODEC, others.[/+]aiChaoSONG commentedon Sep 21, 2020
I think we have two issues there, one is thesofproject/sof-test#379, I am working on this but delayed due to TGL release, the other is
error: in logger_read(), fread(..., /sys/kernel/debug/sof/etrace) failed: Inappropriate ioctl for device, I think it is sof-logger or SOF issue.aiChaoSONG commentedon Sep 21, 2020
@fredoh9 It's the ramp (fade in) which contributing to the frequency.
lgirdwood commentedon Sep 21, 2020
Fwiw, I do manually check all alsa-bat failures by downloading the WAV and listening to the output as well as viewing in audacity. I also remember discussing with @singalsu a while back that we do need to make the pass band window larger.
@singalsu can you comment on the alsa-bat pass band window size do @marc-hb can fix if necessary.
marc-hb commentedon Sep 21, 2020
I shared a fix for this in the comment immediately before yours.
aiChaoSONG commentedon Sep 22, 2020
confirmed two issues are here, create new ones:
close this compond issue
marc-hb commentedon Sep 22, 2020
I didn't understand the purpose of creating a new one instead of keeping this one but 379 is actually an old issue, thanks for closing this duplicate.
aiChaoSONG commentedon Sep 23, 2020
@marc-hb This issue is actually two issues with different code, so I split it