Comments (37)
@kYc0o emb6 issue fixed in RIOT-OS/RIOT#6045
from release-specs.
OK ça roule! :P
from release-specs.
Some strange thing... when I flash any firmware I receive the output as Version: 2017.01-devel ...
is this normal? @miri64 can you check?
from release-specs.
... is this normal? @miri64 can you check?
Yes and I don't need to, but I can explain ;-) Have a look at what commit 2016.10-RC1
is pointing at:
$ git show --decorate 2016.10-RC1
commit f8ec2f1135271d015fa8e1d79b19d9db1135d2d4 (tag: 2017.01-devel, tag: 2016.10-RC1)
Merge: ee698f1 f87dd60
Author: Martine Lenders <[email protected]>
Date: Tue Nov 1 16:05:09 2016 +0100
Merge pull request #5997 from aabadie/nucleo_arduino_pinmap
Provide arduino feature to Nucleo boards
That's the branching-of point of 2016.10-branch
from master
(so the start of the new release). Since 2017.01-devel
is an annotated tag (for the very reason to be picked up by git describe
) git describe
picks up preferred to 2016.10-RC1
which only is a lightweight tag. As soon as we have a 2016.10
release (releases are annotated tags with some GitHub-specific web flavoring ;-)) we git describe
will show the distance from that one.
from release-specs.
@cgundogan @OlegHahm can you look into the output of tests/bloom_bytes
?
from release-specs.
Should I wait for RC2 to continue the tests?
from release-specs.
Yes. Will create it tomorrow morning.
from release-specs.
We are on RC3 already, so please continue with that one.
from release-specs.
Kernel panic in gnrc_sock_udp
:
main(): This is RIOT! (Version: 2017.01-devel-22-g66dfb-bluelatex.saclay.inria.fr-HEAD)
Calling test_sock_udp_create__EADDRINUSE()
Calling test_sock_udp_create__EAFNOSUPPORT()
Calling test_sock_udp_create__EINVAL_addr()
Calling test_sock_udp_create__EINVAL_netif()
Calling test_sock_udp_create__no_endpoints()
Calling test_sock_udp_create__only_local()
Calling test_sock_udp_create__only_local_reuse_ep()
Calling test_sock_udp_create__only_remote()
Calling test_sock_udp_create__full()
Calling test_sock_udp_recv__EADDRNOTAVAIL()
Calling test_sock_udp_recv__EAGAIN()
Calling test_sock_udp_recv__ENOBUFS()
Calling test_sock_udp_recv__EPROTO()
Calling test_sock_udp_recv__ETIMEDOUT()
* Calling sock_udp_recv()
* (timed out with timeout 1000000)
Calling test_sock_udp_recv__socketed()
Calling test_sock_udp_recv__socketed_with_remote()
Calling test_sock_udp_recv__unsocketed()
Calling test_sock_udp_recv__unsocketed_with_remote()
Calling test_sock_udp_recv__with_timeout()
Calling test_sock_udp_recv__non_blocking()
Calling test_sock_udp_send__EAFNOSUPPORT()
Calling test_sock_udp_send__EINVAL_addr()
Calling test_sock_udp_send__EINVAL_netif()
Calling test_sock_udp_send__EINVAL_port()
Calling test_sock_udp_send__ENOTCONN()
Calling test_sock_udp_send__socketed_no_local_no_netif()
0x80011b5
*** RIOT kernel panic:
FAILED ASSERTION.
pid | name | state Q | pri | stack ( used) | base | current
- | isr_stack | - - | - | 512 ( 164) | 0x20000000 | 0x200001c8
1 | idle | pending Q | 15 | 256 ( 128) | 0x20000464 | 0x200004e4
2 | main | running Q | 7 | 1536 ( 720) | 0x20000564 | 0x20000994
3 | ipv6 | bl rx _ | 4 | 1024 ( 300) | 0x200011a0 | 0x20001474
4 | udp | bl rx _ | 5 | 1024 ( 256) | 0x20000d5c | 0x2000105c
| SUM | | | 4352 ( 1568)
*** halted.
from release-specs.
that's a FAILED ASSERTION
. Can you tell me which board you are using and which line the assertion fails (using http://doc.riot-os.org/group__core__util.html#ga2200149ba880bf26fed140bdcf318113)
from release-specs.
Ah, got it already:
tests/gnrc_sock_udp/main.c:455 => 0x8000319
And that's because the packet buffer is not empty nor clean:
(gdb) print *_first_unused
$6 = {next = 0x0, size = 196}
(gdb) print *(gnrc_pktsnip_t *)(_pktbuf + 196)
$9 = {users = 0, next = 0x0, data = 0x20001bb8, size = 0, type = 88}
I'll try to find time to dig into this :-/
from release-specs.
(probably related to RIOT-OS/RIOT#4048?)
from release-specs.
The release specs says that this tests should be done in an iotlab-m3, which is the one I'm using.
from release-specs.
POSIX_SEMAPHORE
fails at TEST 4
:
main(): This is RIOT! (Version: 2017.01-devel-22-g66dfb-bluelatex.saclay.inria.fr-HEAD)
######################### TEST1:
first: sem_init
first: thread create
first: thread created
first: sem_getvalue
first: sem_getvalue != 0
first: do yield
second: sem_trywait
second: sem_trywait failed
second: sem_trywait done with == 0
second: wait for post
first: done yield
first: sem_trywait
first: sem_trywait FAILED
first: sem_trywait done
first: sem_post
second: sem was posted
second: end
first: sem_post done
first: sem_destroy
first: end
######################### TEST2:
first: sem_init
first: thread create: 5
first: thread created: priority 5 (1/5)
first: thread create: 4
first: thread created: priority 4 (2/5)
first: thread create: 3
first: thread created: priority 3 (3/5)
first: thread create: 2
first: thread created: priority 2 (4/5)
first: thread create: 1
first: thread created: priority 1 (5/5)
------------------------------------------
post no. 0
Thread 'priority 1' woke up.
Back in main thread.
post no. 1
Thread 'priority 2' woke up.
Back in main thread.
post no. 2
Thread 'priority 3' woke up.
Back in main thread.
post no. 3
Thread 'priority 4' woke up.
Back in main thread.
post no. 4
Thread 'priority 5' woke up.
Back in main thread.
######################### TEST3:
m3-7;first: sem_init s1
first: sem_init s2
first: create thread 1
first: create thread 2
------------------------------------------
post s1
Thread 1 woke up after waiting for s1.
post s2
Thread 2 woke up after waiting for s2.
post s2
Thread 1 woke up after waiting for s2.
post s1
Thread 2 woke up after waiting for s1.
######################### TEST4:
first: sem_init s1
first: wait 1 sec for s1
first: timed out
first: waited only lu usec => FAILED
first: waited lu usec
######################### DONE
from release-specs.
Just finished the tests on iotlab-m3 with these tests failing:
gnrc_sock_udp
od
posix_semaphore
sizeof_tcb
from release-specs.
How do od
and sizeof_tcb
fail?
from release-specs.
sizeof_tcb
fails at the printing, the output is not formatted and only a "zu" is shown in the results.
od
fails with a pointer which is out of the stack or something like this. I'll provide the exact output.
from release-specs.
Well actually I don't know if it's an expected behaviour or an error, but after a big output of tests for several functions it ends by this:
od(long_str, sizeof(long_str), OD_WIDTH_DEFAULT, OD_FLAGS_BYTES_INT | OD_FLAGS_LENGTH_8)
000000000Stack pointer corrupted, reset to top of stack
FSR/FAR:
CFSR: 0x01000000
HFSR: 0x40000000
DFSR: 0x00000000
AFSR: 0x00000000
Misc
EXC_RET: 0xfffffffd
from release-specs.
I think it fails here:
/* Test different 8-byte-wise byte formats */
CALL(od(long_str, sizeof(long_str), OD_WIDTH_DEFAULT,
OD_FLAGS_BYTES_INT | OD_FLAGS_LENGTH_8));
CALL(od(long_str, sizeof(long_str), OD_WIDTH_DEFAULT,
OD_FLAGS_BYTES_DECIMAL | OD_FLAGS_LENGTH_8));
CALL(od(long_str, sizeof(long_str), OD_WIDTH_DEFAULT,
OD_FLAGS_BYTES_UINT | OD_FLAGS_LENGTH_8));
CALL(od(long_str, sizeof(long_str), OD_WIDTH_DEFAULT,
OD_FLAGS_BYTES_HEX | OD_FLAGS_LENGTH_8));
from release-specs.
For sizeof_tcb
fix is provided in RIOT-OS/RIOT#6078
from release-specs.
Great thanks! testing asap.
from release-specs.
For posix_semaphore
fix is provided at RIOT-OS/RIOT#6079
from release-specs.
od
and gnrc_sock_udp
are a different game. Look into them now.
from release-specs.
Interestingly enough, without optimization the error in od
does not happen :-/
from release-specs.
od
"fixed" in RIOT-OS/RIOT#6080
from release-specs.
Turns out the issue with gnrc_sock_udp was related to RIOT-OS/RIOT#5748. Here's a quick-fix: RIOT-OS/RIOT#6084
from release-specs.
Excellent, everything works well now. I'll move to the next task.
from release-specs.
I hope you stay on RC3 for that! ;-) For gnrc_sock_ip
(which I tested since I was working on gnrc_sock_udp
) you might need RIOT-OS/RIOT#6083. Otherwise this will fail, too. Will write a mail to devel and maintainers about the state of RC4. If you want to wait for that, before continuing testing RC3, I understand.
from release-specs.
Yes! I'm on RC3. Yes I also looked at RIOT-OS/RIOT#6083 and I can retest if needed.
Ok, I can wait for RC4 to move for the tests on samr21-xpro (task 03).
from release-specs.
Ok, I can wait for RC4 to move for the tests on samr21-xpro (task 03).
Might be still of use to prevent an RC5 ;-) Just saying :-).
from release-specs.
I forgot posix_semaphore
and got another error :/ :
######################### TEST1:
first: sem_init
first: thread create
first: thread created
first: sem_getvalue
first: sem_getvalue != 0
first: do yield
second: sem_trywait
second: sem_trywait failed
second: sem_trywait done with == 0
second: wait for post
first: done yield
first: sem_trywait
first: sem_trywait FAILED
1first: sem_trywait done
first: sem_post
second: sem was posted
second: end
first: sem_post done
first: sem_destroy
first: end
from release-specs.
Maybe the timeouts are too short?
from release-specs.
(hit the bad button)
from release-specs.
Maybe the timeouts are too short?
what timeouts?
from release-specs.
Are you sure this is a fail? The test script expects exactly the output you provided
from release-specs.
Oups! just interpreted the failing message as a real failure, and I didn't look at such script. Then these tests are over.
from release-specs.
Superseded by #35
from release-specs.
Related Issues (20)
- Release 2022.04 - RC7 HOT 3
- Rust: describe that crate versions should be bent away from git
- Release 2022.07 - RC1 HOT 16
- Release 2022.07 - RC2 HOT 4
- Release 2022.07 - RC3 HOT 7
- Release 2022.07 - RC4 HOT 25
- Release 2022.10 - RC1 HOT 7
- Release 2022.10 - RC2 HOT 9
- Release 2022.10 - RC3 HOT 18
- Release 2023.01 - RC1 HOT 3
- Release 2023.01 - RC2 HOT 2
- Release 2023.01 - RC3 HOT 14
- 08 - Task 11: Building zephyr on atsamr21_xpro not possible HOT 4
- Release 2023.04 - RC1 HOT 12
- [RFC] Restructure/update Release Specs HOT 2
- Release 2023.04 - RC2 HOT 5
- Release 2023.04 - RC3 HOT 3
- Release 2023.07 - RC5 HOT 15
- Release 2023.10 - RC1 HOT 11
- Release 2023.10 - RC2 HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from release-specs.