Re: [RTnet-users] System-freeze while using rttcp and rtudp in parallel
On Sun, Jun 28, 2015 at 04:24:42PM +0200, Jan Kiszka wrote: - transfer of setup into QEMU/KVM, then using built-in gdbstub (works like a hardware debugger, just cheaper and faster) You can't be faster than a JTAG debugger. With a JTAG debugger, the processor runs at full speed, with QEMU, even with KVM it does not, because some things are still emulated. For instance, if your processor does not support what is called extended page tables, the job of handling the MMU page tables is emulated in the qemu host, and that hurts. If you look at the second column of the list on intel website: http://ark.intel.com/Products/VirtualizationTechnology You will see that even though all core i* processors support EPT, older processors do not, and very few Atom processors do. By contrast, even the lowest end processor that supports JTAG (and I have never met one which did not) does not need to emulate its MMU when running in a debugger. -- Gilles. https://click-hack.org pgp0_NCRKIz5B.pgp Description: PGP signature -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] System-freeze while using rttcp and rtudp in parallel
On 2015-06-23 10:38, thomas.wittm...@still.de wrote: Hello everybody, we have a strange behavior with RTnet and need some help. We are using a sensor tethered via Ethernet to a rteth-NIC exclusively. The sensor has to be configured, started and stopped with short http-commands. For this we are using the RTnet tcp-module. The continuous sensor-data itself are provided with UDP and for this we are using the RTnet udp-module. Thus far everything works fine. When we sent http-commands for e.g. startup to a second sensor connected to a second rteth-NIC and the first sensor is already in continuous-data delivering mode (UDP), the whole operating-system freezes and there is no response anymore. So we are not able to debug anything. This happens often, if the data-volume of the continuous-data is small, and it crashes nearly always, if the data-volume is larger. In this case, both threads are running at the same cpu. We find out, when we switch one of the threads to another cpu, everything seems to work fine, but we have no long-term experiences yet. In addition this approach seems to be just a work-around. Is the Xenomai watchdog enabled, to catch run-away threads? If you have some ideas, remarks or if you need more information, please let me know. Thank you! There are plenty of ways to debug even such hard freezes (well, most of them). First of all, make sure you have a serial console working and the kernel reporting to it. Then these are some of your options: - NMI watchdog (should throw a backtrace after some seconds) - I-pipe and Xenomai self-checks (build-time switches - may catch lockups or illicit API uses) - step-wise instrumentation of code to narrow-down the lockup (tedious work, I know) - hardware debugger (JTAG), less common on x86 - I suspect you are on that arch - transfer of setup into QEMU/KVM, then using built-in gdbstub (works like a hardware debugger, just cheaper and faster) HTH, Jan signature.asc Description: OpenPGP digital signature -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
[RTnet-users] System-freeze while using rttcp and rtudp in parallel
Hello everybody, we have a strange behavior with RTnet and need some help. We are using a sensor tethered via Ethernet to a rteth-NIC exclusively. The sensor has to be configured, started and stopped with short http-commands. For this we are using the RTnet tcp-module. The continuous sensor-data itself are provided with UDP and for this we are using the RTnet udp-module. Thus far everything works fine. When we sent http-commands for e.g. startup to a second sensor connected to a second rteth-NIC and the first sensor is already in continuous-data delivering mode (UDP), the whole operating-system freezes and there is no response anymore. So we are not able to debug anything. This happens often, if the data-volume of the continuous-data is small, and it crashes nearly always, if the data-volume is larger. In this case, both threads are running at the same cpu. We find out, when we switch one of the threads to another cpu, everything seems to work fine, but we have no long-term experiences yet. In addition this approach seems to be just a work-around. If you have some ideas, remarks or if you need more information, please let me know. Thank you! Software versions: - Linux kernel 3.8.13 - Xenomai 2.6.3 - RTnet 0.9.13.-08.2013 Best regards/ Mit freundlichen Grüßen Thomas Wittmann STILL GmbH, Sitz der Gesellschaft: Hamburg, Registergericht: Hamburg HRB 11168, Ust-IdNr. DE 811145412, Aufsichtsrat: Dr. Thomas Toepfer (Vorsitzender), Geschäftsführung: Gordon Riske (Vorsitzender), Thomas A. Fischer, Goran Mihajlovic, Olaf Schulz -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
