Re: Nucleo f030r8 fails at QEMU Cortex M3 test


Boie, Andrew P
 

The deeper context here is that we have a number of timing-sensitive tests which sometimes fall over if the server running sanitycheck is heavily loaded. AFAICT, this is due to QEMU trying to synchronize the emulated system timer with the host workstation timer.

To date, nobody have been able to figure out a way to get QEMU to act differently. What we want is for the emulated system to be completely detached from the host system's sense of timing. Anyone who can figure this out, patches would be most welcome.

Andrew

-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Nashif, Anas
Sent: Monday, August 14, 2017 8:39 AM
To: Paul Sokolovsky <paul.sokolovsky@...>; Maciej Debski <maciej.debski@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] Nucleo f030r8 fails at QEMU Cortex M3 test

Hi,
There was an issue in how we re-run sanitycheck on failed tests (retry) to eliminate false positive due to heavy load and Qemu not being able to deal with that. This is now fixed.

Anas

-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Paul Sokolovsky
Sent: Monday, August 14, 2017 11:25 AM
To: Maciej Dębski <maciej.debski@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] Nucleo f030r8 fails at QEMU Cortex M3 test

Hello Maciej,

On Mon, 14 Aug 2017 11:31:44 +0200
Maciej Dębski <maciej.debski@...> wrote:

Hello,

I just posted a pull request for my nucleo f030r8 support. Here it is:
https://github.com/zephyrproject-rtos/zephyr/pull/1103

The shippable ran all the tests correctly, just one with a failure,
which is:
*Sanitycheck / qemu_cortex_m3:tests/net/ieee802154/l2/test /
qemu_cortex_m3/tests/net/ieee802154/l2/test*

As far as I believe, this test is not related to my board. I am not
sure though. Could you give me some information on how I should react
to this? How can I correct this? What does the test mean? Is there a
way to not test my code with it?
*All* tests fail sooner or later, with or without a reason. (As Murphy would add, non-tests fail sooner or later too.) If you're sure it's random failure not related to your changes, then you just need to resubmit your pull request to trigger a new CI build. To resubmit a PR, its commit revisions should change. The easiest way to achieve that is to rebase on the latest master. If it happens that nobody pushed any new commits to master yet, then you can do something like:

git rebase --ignore-date HEAD^

This will update date of your last commit, thus changing its revision, and will allow to force-push the PR as usual.


Thank you for help,
Maciej Dębski


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog _______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

Join devel@lists.zephyrproject.org to automatically receive all group messages.