On 2012-10-26 16:09, Michael Morscher wrote: > Hi Jan, > > Thank for the answer. > > Am Freitag, 26. Oktober 2012 15:38 CEST, Jan Kiszka <jan.kis...@siemens.com> > schrieb: > >> On 2012-10-25 10:58, Michael Morscher wrote: >>> Hey guys, >>> >>> Just ran into some strange behaviour on my test rig. (2x MPC8313E-RDB +2x >>> Intel E1000 PCI) >>> >>> 1. After starting the master server, I'm getting loads of those messages: >>> >>>TDMA: Failed to transmit sync frame! >>> instead of the normal "waiting for slaves...". I need to start the slave >>> first and let him "search for master..." and then the master to get the >>> RTnet handshake... >>> >>> 2. When I'm trying to stop the rtnet service, I'm getting an PCI / DMA >>> problem: >> >> What are the vendor:device IDs of your NICs? Do they also happen to work >> with the rt_e1000e (likely if they are newer cards)? Then that driver >> should be preferred. > > lspci gives me: > 00:0f.0 Ethernet controller [0200]: Intel Corporation 82541PI Gigabit > Ethernet Controller [8086:107c] (rev 05)
Ok, that's an old adapter, and you are using the right driver. > Subsystem: Intel Corporation PRO/1000 GT Desktop Adapter [8086:1376] > Flags: bus master, 66MHz, medium devsel, latency 128, IRQ 17 > Memory at 90000000 (32-bit, non-prefetchable) [size=128K] > Memory at 90020000 (32-bit, non-prefetchable) [size=128K] > I/O ports at 1000 [size=64] > [virtual] Expansion ROM at 80000000 [disabled] [size=128K] > Capabilities: [dc] Power Management version 2 > Capabilities: [e4] PCI-X non-bridge device > Kernel driver in use: rt_e1000 > Kernel modules: e1000 > > Actually removing the PCI Adress from the REBIND_RT_NICS solved the > start/stoping issue. Thought that this would help, but maybe I didn't get the > purpose of this variable. The purpose is to tell Linux to unbind the active driver (e1000) from the card and bind the rt_e1000 instead. As long as there is only one adapter of the same kind, it's basically "rmmod e1000; modprobe rt_e1000" (and "rmmod rt_e1000; modprobe e1000" on stop). I don't know what you are doing instead, so I cannot asses the difference. I guess there is a general bug in rt_e1000 regarding unload and that hardware. Does avoiding the rebind solve your first issue with TDMA? > >> >>> >>> After that, It looks like he cannot access the DMA again. Only a reboot >>> fixes that. >>> > >>> >>> 3. While trying to use the rtping tool, I'm getting a lot variation in the >>> output data. Is that normal? >> >> If you have TDMA enabled, reply times are following the time slots and >> may jump as the injection point shifts/jitters. >> >> Jan > > Are there any other variables or modes supported in RTnet? Actually there is > a variable but I can only find the patch that adds it :) > (RT_PROTOCOLS="udp packet") and no documentation. RT_PROTOCOLS is targeting at protocols presented to applications, not RTmac protocols. "tcp" would be the third option here. > > Have you got any results what bandwidth you achieved? Or anyone? I've no numbers on maximum bandwidth as high throughput was no requirement in projects I dealt with so far. If you enable TDMA, you can easily derive the upper limit from your config, though. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
