Re: [riot-devel] question on a possibility for a netdev deadlock
Ahh, thx for clarification. Best regards, Martin Am 24.06.2015 um 10:14 schrieb Daniel Krebs: Hi Martin, all the mentioned function are not called in interrupt context. Take a look at ng_at86rf2xx.c. There you find the real ISR that sends a msg to the next higher level notifying about the IRQ. Then from there everything else in the driver is executed from thread context. So I guess this is unrelated to the problems you are having. Cheers, Daniel Am 24. Juni 2015 09:54:09 MESZ, schrieb Martin martin.landsm...@haw-hamburg.de: Hi all, I've tested the ng_ stack with samr21-xpro boards using the new ng_at86rf2xx driver. Since I sometimes encountered hardfaults I took a look in the ISR handling of the driver [1]. There we handle incoming packets when the receiver has finished the RX process [2]. Since we are in a ISR, all other processes has been interrupted. Now when we call _receive_data() function inside the ISR, that in turn calls pktbuf handling/manipulating functions [3], we try to acquire the mutex protecting the pktbuf [4]. Since we are still inside of the ISR probably the mutex is acquired by someone else. If true this leads to a deadlock since the ISR would wait forever to acquire the mutex and never return to leave the ISR. Additionally if we successfully acquire the mutex, we could produce inconsistencies iff the protection is not performed consistently. Just wanted to ask if I'm mistaken here and missed something. Best regards, Martin [1] https://github.com/RIOT-OS/RIOT/blob/master/drivers/ng_at86rf2xx/ng_at86rf2xx_netdev.c#L671 [2] https://github.com/RIOT-OS/RIOT/blob/master/drivers/ng_at86rf2xx/ng_at86rf2xx_netdev.c#L688 [3] https://github.com/RIOT-OS/RIOT/blob/master/drivers/ng_at86rf2xx/ng_at86rf2xx_netdev.c#L271 [4] https://github.com/RIOT-OS/RIOT/blob/master/sys/net/crosslayer/ng_pktbuf/ng_pktbuf.c#L81 devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] question on a possibility for a netdev deadlock
Hi Martin, all the mentioned function are not called in interrupt context. Take a look at ng_at86rf2xx.c. There you find the real ISR that sends a msg to the next higher level notifying about the IRQ. Then from there everything else in the driver is executed from thread context. So I guess this is unrelated to the problems you are having. Cheers, Daniel Am 24. Juni 2015 09:54:09 MESZ, schrieb Martin martin.landsm...@haw-hamburg.de: Hi all, I've tested the ng_ stack with samr21-xpro boards using the new ng_at86rf2xx driver. Since I sometimes encountered hardfaults I took a look in the ISR handling of the driver [1]. There we handle incoming packets when the receiver has finished the RX process [2]. Since we are in a ISR, all other processes has been interrupted. Now when we call _receive_data() function inside the ISR, that in turn calls pktbuf handling/manipulating functions [3], we try to acquire the mutex protecting the pktbuf [4]. Since we are still inside of the ISR probably the mutex is acquired by someone else. If true this leads to a deadlock since the ISR would wait forever to acquire the mutex and never return to leave the ISR. Additionally if we successfully acquire the mutex, we could produce inconsistencies iff the protection is not performed consistently. Just wanted to ask if I'm mistaken here and missed something. Best regards, Martin [1] https://github.com/RIOT-OS/RIOT/blob/master/drivers/ng_at86rf2xx/ng_at86rf2xx_netdev.c#L671 [2] https://github.com/RIOT-OS/RIOT/blob/master/drivers/ng_at86rf2xx/ng_at86rf2xx_netdev.c#L688 [3] https://github.com/RIOT-OS/RIOT/blob/master/drivers/ng_at86rf2xx/ng_at86rf2xx_netdev.c#L271 [4] https://github.com/RIOT-OS/RIOT/blob/master/sys/net/crosslayer/ng_pktbuf/ng_pktbuf.c#L81 ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Connectivity between new NG stack and loopback
Hello everyone, I'm new to RIOT and currently trying to test the connectivity between a RIOT instance on native and the loopback. I'm currently using the ng_networking.elf from the examples and while I can pass messages between 2 RIOT instances using this example I would also like to be able to have a connection with the loopback on my machine for future tests but I can't seem to make it work. If someone could give me a quick walkthrough or help me figure out where my mistake is I would really appreciate it. I'm sure this must seem trivial . Thank you, Alex ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Connectivity between new NG stack and loopback
Hello Alexandru, I am not certain that this method is bullet-proof, but you can try the following: * Create a tun/tap interface: sudo openvpn --mktun --dev tap0 [FYI: I did not test this method with the tapsetup script] * Enable the interface: sudo ip link set dev tap0 up * start ng-nativenet make term PORT=tap0 [FYI: Starting RIOT with tap0 will assign an ip address to tap0] * In Linux: lookup the ipv6 address of tap0 ifconfig tap0 * Start a udp server on Linux nc -ul ip-address of tap0%tap0 13377 [ It is necessary to use the suffix %tap0 in order to give a hint to Linux that this is a tun/tap device] * In RIOT: start a udp server and happily communicate with linux udp server start 13377 udp send ip-address of tap0 13377 HELLO-RIOT * In Linux: netcat will receive this message and you can reply by just typing something in your shell I hope this helps cheers, Cenk On 24.06.2015 10:40, Alexandru Razvan Caciulescu wrote: Hello everyone, I'm new to RIOT and currently trying to test the connectivity between a RIOT instance on native and the loopback. I'm currently using the ng_networking.elf from the examples and while I can pass messages between 2 RIOT instances using this example I would also like to be able to have a connection with the loopback on my machine for future tests but I can't seem to make it work. If someone could give me a quick walkthrough or help me figure out where my mistake is I would really appreciate it. I'm sure this must seem trivial . Thank you, Alex ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Connectivity between new NG stack and loopback
Hi Alex, have a look at the microcoap example [1], which uses marz [2] to connect the RIOT node with your »normal« localhost. The RIOT application in this example is a just a server (and only reacts on requests), but it shouldn't be too hard to extend/customize. The marz code is a bit spaghetti like, and maybe I will build a better solution in the near future, as I need the same functionality you do for testing a gateway. As for the microcoap example: beware of pip, you may want to install Twisted and bidict manually by downloading it from the respective websites, because (on my system) pip installed only parts of the libraries. Also, check the $PYTHONPATH variable and which version of python the respective file/program uses when things don't work, this caused some trouble for me. As soon as I know more, I'll let you know. The method described by Cenk did not work for me, but I'll try and make that (or something similar) work as well. Best, Lennart [1] https://github.com/RIOT-OS/applications/tree/master/microcoap [2] https://github.com/sgso/marz ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Connectivity between new NG stack and loopback
Hello Lennart, I might be wrong and Sebastian might be able to shed some light on this, BUT isn't marz restricted to the old network stack? As far as I know it strips/adds the old nativenet header from outgress/ingress packets. BTW, are you also using the old network stack? My described method works only for the new network stack and with ng_nativenet (: cheers, CG On 24.06.2015 19:27, Lennart Dührsen wrote: Hi Alex, have a look at the microcoap example [1], which uses marz [2] to connect the RIOT node with your »normal« localhost. The RIOT application in this example is a just a server (and only reacts on requests), but it shouldn't be too hard to extend/customize. The marz code is a bit spaghetti like, and maybe I will build a better solution in the near future, as I need the same functionality you do for testing a gateway. As for the microcoap example: beware of pip, you may want to install Twisted and bidict manually by downloading it from the respective websites, because (on my system) pip installed only parts of the libraries. Also, check the $PYTHONPATH variable and which version of python the respective file/program uses when things don't work, this caused some trouble for me. As soon as I know more, I'll let you know. The method described by Cenk did not work for me, but I'll try and make that (or something similar) work as well. Best, Lennart [1] https://github.com/RIOT-OS/applications/tree/master/microcoap [2] https://github.com/sgso/marz ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
