Open kaspar030 opened 2 years ago
seems like it is not unlikely that these emulates tests fail due to timing issues
(I ran the tests at my laptop and they succeeded)
yes, very likely. do you want to open a blacklist PR?
I am not sure since it does not seem happen often (only one other PR shows this atm "PR #16771 build at 11/04/2022, 13:27:52") (maybe this happens when the building server has to much other load?) On the other hand ci.riot / murdock shows only the latest run of a PR. Maybe you have a better view at the past failing builds? (could we ignore the results but still run the test?)
Some of these timeouts might be solved by setting RIOT_TEST_TIMEOUT
for emulated microbit
https://ci.riot-os.org/RIOT-OS/RIOT/17096/c7638d84ae5a709d6634ffe81dbce6828ecbab3f/output/compile/tests/pbkdf2/microbit:gnu.txt https://ci.riot-os.org/RIOT-OS/RIOT/16771/5a6b007467d22bee4ec7278782d272d8df7cd4d5/output/compile/tests/event_wait_timeout/microbit:gnu.txt https://ci.riot-os.org/RIOT-OS/RIOT/16771/5a6b007467d22bee4ec7278782d272d8df7cd4d5/output/compile/tests/pbkdf2/microbit:gnu.txt
https://qemu.readthedocs.io/en/latest/system/arm/nrf.html
maybe we should make the emulated microbit a seperate board (with a different feature set)
Description
https://github.com/RIOT-OS/RIOT/pull/17434 enables CI to test for microbit emulated with qemu. Some tests fail. To get it in, they have been CI blacklisted for further investigation.
IMO, they all need to be checked if the failure is related to qemu not emulating hardware, or qemu not being exact enough (timing off?), or something wrong with the setup (pyterm seems to make some tests fail?). So I dump the list here.
As a reminder, if qemu is installed (qemu-system-arm needs to be available), a test can be run like this:
Missing rtt:
Not exact enough:
Unknown:
Steps to reproduce the issue
Expected results
Actual results
Versions