-
Notifications
You must be signed in to change notification settings - Fork 21
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
Release 2020.01 - RC2 #146
Comments
Summarizing RC1 tests: The following tests failed, where I 99-run tests Task #1 and 04-single-hop-6lowpan-icmp Task #10 should be re-ran,the others are expected to fail.
Tests that were not run in RC1, here I'll investigate 04-single-hop-6lowpan-icmp Task #7 04-single-hop-6lowpan-icmp Task #6 tomorrow.
|
PR's merged between RC1 and RC2:
|
@miri64(or anyone else in Berlin) if possible could you plug and un-plug:
all tests failed las run on |
I'll have a look |
Done (I hope I got all... I wasn't sure how the ek-lm4f120xl looks like ^^") |
Thanks! (me neither hahaha) |
03-single-hop-ipv6-icmp Task 6 RC2 Passesnative 1
native 2
|
@miri64 besides 03.3 and 04.10 any other tasks that should be re-ran because of RIOT-OS/RIOT#13169 ? |
No, only the tests mentioned cover that segment of code fixed in RIOT-OS/RIOT#13169. |
I'll re-run:
And tomorrow tackle:
IMO only board or cpu specific fixes might still get in, and if it need arises some fix to |
Ran 10 times. (should have cat terminal output to a file, lost some of it :D) 04-single-6lowpan-icmp Task 10 RC2 Passes
|
To the chunks disappear or why did you give it a pass? |
Yes I'm using a script that sends |
e.g (taken from the output pasted above):
|
Seems legit. The reassembly buffer timeout for IPv6 is IIRC 10 seconds. |
Here is the script I used BTW, still working on it. And there are some setup requirements. |
|
Sending and receiving messages when compiling |
It also answers to multicast:
|
This behaviour was not present in
|
Bisecting I found that RIOT-OS/RIOT#11879 broke this for To summarize with the introduction of RIOT-OS/RIOT#11879 when using and note: there is arduino-zero+xbee on iotlab so you can reproduce. |
@fjmolinas we are on it |
@fjmolinas check RIOT-OS/RIOT#13192 |
I was trying to check that RIOT-OS/RIOT#13192 made Basically increasing the packet size or reducing the interval cause it to fail after a couple of pings (os straight away), the pinger stops receiving echos and on
which makes me think it hard-faulted and failed to init the netdev interface. The board needs then to be reset for it work again. I was able to reproduce the same behavior on 2019.10. I'm not sure what interval was used for this task in 2019.10 @MrKevinWeiss do you recall? I then enabled debugging and that is exactly what is happening, continuous reboots until pinging stops or it fails to init the interface.
If I change the baudrate and |
Seems like when overstressed if it tries to send a packet it fails and then reboots.
|
Even if over stressed the node should still be working here so this seems like a bug to me, but I'm unsure how it's triggered, and since this is related to If a fix is found It can be back-ported but, for now I would rather add it to known issues. If someone else is willing to dive in to this and try to fix before the Release it would be great. @aabadie @miri64 any thoughts on this, does it seem like an Ok way to go? |
I don't think it passed on the old release as it was listed experimental and it wasn't checked off. I do remember running some interop tests with IoT labs and some nodes would have this fail to initialize and I would have to restart a bunch, @PeterKietzmann had this problem too. It does say on an earlier task that I used a size of 50B instead of 100... maybe that was it. |
Me too. I think we never mentioned it in the release notes, because the task is marked experimental and because IIRC for local tests it worked. |
However, in retrospective, it might make sense to open a dedicated issue for this, even if it turns out just a problem specific to the nodes in the IoT-LAB. |
I was checked on RC2:
|
I've investigated a little more, the issue with the hardfault seems to be related to |
Ok, so I figured out the issue. When using an arduion breakout board CTS pin of the xbee is connected to RESET on ICPS connector, so when xbee asserts this line it causes a reset. |
That might explain why I never had this issue locally. Whenever I tested with a board |
FYI I'm currently waiting on RIOT-OS/RIOT#13212 to open RC3 and finalize this release. |
Closing in favor of #148 |
This issue lists the status of all tests for the Release Candidate 2 of the 2020.01 release.
Specs tested:
The text was updated successfully, but these errors were encountered: