Skip to content
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.

Sign up for GitHub

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

Jump to bottom

02-tests/task 02 Release 2016.10 - RC3 #26

Closed
kYc0o opened this issue Nov 2, 2016 · 37 comments
Closed

02-tests/task 02 Release 2016.10 - RC3 #26

kYc0o opened this issue Nov 2, 2016 · 37 comments

Comments

@kYc0o
Copy link
Contributor

kYc0o commented Nov 2, 2016 •
edited

Task # 02

Perform a subset of tests on iotlab-m3 node:

  • bitarithm_timings
  • bloom_bytes OK but don't know if the output is right:
INFO # checking 10000 elements took 2145ms
INFO # 
INFO # 267 elements probably in the filter.
INFO # 9733 elements not in the filter.
INFO #  false positive rate.
INFO # 
INFO # All done!
  • coap
  • conn_ip
  • cpp11_condition_variable OK
  • cpp11_mutex
  • cpp11_thread OK
  • driver_adt7310
  • driver_at30tse75x
  • driver_at86rf2xx OK
  • driver_bh1750
  • driver_bmp180 OK Results in error as expected
  • driver_dht
  • driver_enc28j60
  • driver_encx24j600
  • driver_hdc1000 OK Results in error as expected
  • driver_hih6130
  • driver_ina220
  • driver_io1_xplained
  • driver_isl29020 OK
  • driver_isl29125
  • driver_kw2xrf
  • driver_l3g4200d OK
  • driver_lis3dh
  • driver_lis3mdl
  • driver_lpd8808
  • driver_lps331ap OK
  • driver_lsm303dlhc
  • driver_mag3110
  • driver_mma8652 OK Results in error as expected
  • driver_mpl3115a2
  • driver_mpu9150
  • driver_mq3 OK Lectures are 0 since there's no sensor
  • driver_nrf24l01p_lowlevel
  • driver_nrfmin
  • driver_nvram_spi
  • driver_pcd8544 OK
  • driver_pir
  • driver_servo
  • driver_si70xx OK Results in error as expected
  • driver_srf02
  • driver_srf08
  • driver_tcs37727 OK Results in error as expected
  • driver_tmp006
  • driver_xbee
  • emb6 OK
  • fault_handler
  • float
  • fmt_print OK
  • gnrc_ipv6_ext
  • gnrc_sixlowpan
  • gnrc_sock_ip OK
  • gnrc_sock_udp OK
  • irq
  • leds
  • libfixmath
  • lwip OK
  • malloc
  • minimal
  • mpu_stack_guard OK Fails because iotlab-m3 is not whitelisted
  • msg_send_receive OK
  • msg_try_receive
  • mutex_order
  • mutex_unlock_and_sleep OK
  • netdev2_test
  • netstats_l2
  • nhdp OK but fails in OS X
  • od OK
  • periph_adc
  • periph_cpuid
  • periph_dac OK compiles and runs but there's no DAC for iotlab-m3
  • periph_gpio
  • periph_hwrng
  • periph_i2c OK sensors work as expected
  • periph_pwm
  • periph_rtc
  • periph_rtt OK
  • periph_spi
  • periph_timer
  • periph_uart OK
  • pipe
  • pkg_aversiveplusplus OK
  • pkg_cmsis-dsp
  • pkg_jsmn OK
  • pkg_micro-ecc
  • pkg_tiny-asn1 OK
  • pkg_u8g2
  • posix_semaphore OK
  • posix_sleep
  • pthread
  • pthread_barrier OK
  • pthread_cleanup
  • pthread_condition_variable
  • pthread_cooperation OK
  • pthread_rwlock
  • pthread_tls
  • saul OK
  • sched_testing
  • shell
  • sizeof_tcb OK
  • slip
  • struct_tm_utility
  • thread_basic OK
  • thread_cooperation
  • thread_exit
  • thread_flags OK
  • thread_flood
  • thread_msg
  • thread_msg_avail OK
  • thread_msg_block_wo_queue
  • thread_msg_block_w_queue
  • thread_msg_seq OK
  • warn_conflict
  • xtimer_drift
  • xtimer_hang OK
  • xtimer_longterm
  • xtimer_msg
  • xtimer_msg_receive_timeout OK
  • xtimer_now64_continuity
  • xtimer_periodic_wakeup OK
  • xtimer_remove
  • xtimer_reset OK
  • xtimer_shift_on_compare
  • zep

This list is based on previous #23 with different test marked for this release. I also added the new ones which are systematically performed.
@kYc0o
Copy link
Contributor Author

kYc0o commented Nov 2, 2016

Some strange thing... when I flash any firmware I receive the output as Version: 2017.01-devel ... is this normal? @miri64 can you check?

@miri64 miri64 mentioned this issue Nov 2, 2016
Closed
37 tasks
@miri64
Copy link
Member

miri64 commented Nov 3, 2016

... 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 <authmillenon@gmail.com>
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.

@miri64
Copy link
Member

miri64 commented Nov 3, 2016

@cgundogan @OlegHahm can you look into the output of tests/bloom_bytes?

@miri64 miri64 mentioned this issue Nov 3, 2016
Closed
59 tasks
@miri64
Copy link
Member

miri64 commented Nov 3, 2016

@kYc0o emb6 issue fixed in RIOT-OS/RIOT#6045

@kYc0o
Copy link
Contributor Author

kYc0o commented Nov 3, 2016

Should I wait for RC2 to continue the tests?

@miri64
Copy link
Member

miri64 commented Nov 4, 2016

Yes. Will create it tomorrow morning.

@miri64 miri64 closed this as completed Nov 4, 2016
@miri64 miri64 reopened this Nov 4, 2016
@miri64
Copy link
Member

miri64 commented Nov 5, 2016

We are on RC3 already, so please continue with that one.

@kYc0o
Copy link
Contributor Author

kYc0o commented Nov 5, 2016

OK ça roule! :P

@kYc0o kYc0o changed the title 02-tests/task 02 Release 2016.10 - RC1 02-tests/task 02 Release 2016.10 - RC3 Nov 7, 2016
@kYc0o
Copy link
Contributor Author

kYc0o commented Nov 7, 2016

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.

@miri64
Copy link
Member

miri64 commented Nov 7, 2016

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)

@miri64
Copy link
Member

miri64 commented Nov 7, 2016

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 :-/

@miri64
Copy link
Member

miri64 commented Nov 7, 2016

(probably related to RIOT-OS/RIOT#4048?)

@kYc0o
Copy link
Contributor Author

kYc0o commented Nov 7, 2016

The release specs says that this tests should be done in an iotlab-m3, which is the one I'm using.

@kYc0o
Copy link
Contributor Author

kYc0o commented Nov 7, 2016

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

@kYc0o
Copy link
Contributor Author

kYc0o commented Nov 7, 2016

Just finished the tests on iotlab-m3 with these tests failing:

gnrc_sock_udp 
od
posix_semaphore
sizeof_tcb

@miri64
Copy link
Member

miri64 commented Nov 8, 2016

How do od and sizeof_tcb fail?

@kYc0o
Copy link
Contributor Author

kYc0o commented Nov 8, 2016

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.

@kYc0o
Copy link
Contributor Author

kYc0o commented Nov 8, 2016

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

@kYc0o
Copy link
Contributor Author

kYc0o commented Nov 8, 2016

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));

@miri64
Copy link
Member

miri64 commented Nov 8, 2016

For sizeof_tcb fix is provided in RIOT-OS/RIOT#6078

@kYc0o
Copy link
Contributor Author

kYc0o commented Nov 8, 2016

Great thanks! testing asap.

@miri64
Copy link
Member

miri64 commented Nov 8, 2016

For posix_semaphore fix is provided at RIOT-OS/RIOT#6079

@miri64
Copy link
Member

miri64 commented Nov 8, 2016

od and gnrc_sock_udp are a different game. Look into them now.

@miri64
Copy link
Member

miri64 commented Nov 8, 2016

Interestingly enough, without optimization the error in od does not happen :-/

@miri64
Copy link
Member

miri64 commented Nov 8, 2016

od "fixed" in RIOT-OS/RIOT#6080

@miri64
Copy link
Member

miri64 commented Nov 8, 2016 •
edited

Turns out the issue with gnrc_sock_udp was related to RIOT-OS/RIOT#5748. Here's a quick-fix: RIOT-OS/RIOT#6084

@kYc0o
Copy link
Contributor Author

kYc0o commented Nov 8, 2016

Excellent, everything works well now. I'll move to the next task.

@miri64
Copy link
Member

miri64 commented Nov 8, 2016

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.

@kYc0o
Copy link
Contributor Author

kYc0o commented Nov 8, 2016

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).

@miri64
Copy link
Member

miri64 commented Nov 8, 2016

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 :-).

@kYc0o
Copy link
Contributor Author

kYc0o commented Nov 8, 2016

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

@kYc0o
Copy link
Contributor Author

kYc0o commented Nov 8, 2016

Maybe the timeouts are too short?

@kYc0o kYc0o closed this as completed Nov 8, 2016
@kYc0o kYc0o reopened this Nov 8, 2016
@kYc0o
Copy link
Contributor Author

kYc0o commented Nov 8, 2016

(hit the bad button)

@miri64
Copy link
Member

miri64 commented Nov 8, 2016

Maybe the timeouts are too short?

what timeouts?

@miri64
Copy link
Member

miri64 commented Nov 8, 2016

Are you sure this is a fail? The test script expects exactly the output you provided

@kYc0o
Copy link
Contributor Author

kYc0o commented Nov 8, 2016

Oups! just interpreted the failing message as a real failure, and I didn't look at such script. Then these tests are over.

@miri64 miri64 mentioned this issue Nov 10, 2016
Closed
59 tasks
@miri64
Copy link
Member

miri64 commented Nov 10, 2016

Superseded by #35

@miri64 miri64 closed this as completed Nov 10, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@miri64 @kYc0o