Hi Alex, I finally found the source of my lock ups yesterday, a problem with losing edge detected interrupts.
Anyway I've found a workaround and managed to do some testing, I have had a the two way ping running all night, one with 1000 byte payload the other with 777 byte payload at an interval of 0.4 seconds and this was fine. I also got each board to ssh into the other and the ping itself to introduce some SSH/TCP traffic and this was ok. Finally setup a coap server on one board and in a loop requested the main title page which is a long enough string to require fragmentation to test CoAP/UDP and this was ok. I couldn't get the atftp server working sadly, it's failing to bind to IPv6 addresses for some reason on my board, ethernet or 802154. I will try and fix this and try some large transfers later :) Your patches get the thumbs up from me. Great work Alex. You can add a Tested-by: Martin Townsend <martin.towns...@xsilon.com> Cheers, Martin. On 14/02/14 12:56, Alexander Aring wrote: > Hi, > > I abort my ping6 now, results are: > > --- fe80::a8aa:aaaa:aaaa:aabb%lowpan0 ping statistics --- > 39931 packets transmitted, 39930 received, 0% packet loss, time 12005152ms > rtt min/avg/max/mdev = 154.164/163.993/175.157/2.782 ms > > so these are very very good! I only lost one packet and maybe this one > because I abort it... wow. Never got such a good result like this. > > On Fri, Feb 14, 2014 at 12:35:29PM +0000, Martin Townsend wrote: >> Hi Alex, >> >> I found that tx_queue_len is exported to sysfs >> /sys/class/net/wpan0/tx_queue_len >> >> So I tried a few values. first a value of 50 and all was well in that pings >> still worked. So I tried to ssh from one board to the other >> ssh -6 root@fe80::a200:0:0:1%lowpan0 and it locked up. So I rebooted and >> increased tx_queue_len to 600 and this time I could ssh from one board to >> the other. I don't understand why filling up the tx queue should cause a >> lock up, I'll have a look through the tx queuing source code and see if >> there's something my driver is doing that is upsetting it. >> I don't suppose you could try a low tx_queue_len and see if you can get it >> to lock up by using ssh. >> > I don't know what I should test now? Can write some shellscript and I > will run it on my setup. Then I need two shellscript's one's which I > should run on node 1 and another which I should run on node 2. > > Maybe your problem isn't the tx_queue_len thing. :( I have no idea. > > Note my setup are two atusb devices running in two qemu vm's on one host > pc. :-) > > - Alex ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
