Hi Jan, I ran into another or the same problem again. I switched platform to two Freescale P2020RDB and two Intel e1000e PCI-Express Adapters (Desktop CT). I think the TDMA problem occurs because the buffer of the card explodes. Il receive those messages when I connect both systems with a 1:1 connection. During the loading of the rt_e1000e module, the Link goes down. I think the master then tries to start the calibration phase but the Link isn't up again because the second system also unloaded the module... So RTnet writes pakets into the card's buffer which cannot be sent due to the missing link...
When I connect both systems over a switch, it works perfectly! Sometimes it also work over a 1:1 connection, but not really often. Tried it for half an hour and got it working twice... The calibration time on 1:1 is 10us and over my HP 1810-24G around 12-13us. Cheers Michael Am Freitag, 26. Oktober 2012 17:21 CEST, "Michael Morscher" <michael.morsc...@hs-augsburg.de> schrieb: > Hi Jan, > > When doing a correct start i get: > > root@nfs1-webcam:~# /usr/local/rtnet/sbin/rtnet stop > RTmac/TDMA: unloaded > RTmac: unloaded > RTcfg: unloaded > removing loopback... > RTnet: unregistered rtlo > RTnet: unregistered rteth0 > RTnet: unloaded > > root@nfs1-webcam:~# /usr/local/rtnet/sbin/rtnet start > *** RTnet 0.9.13 - built on Sep 30 2012 20:51:55 *** > RTnet: initialising real-time networking > Intel(R) PRO/1000 Network Driver - version 7.1.9 > Copyright (c) 1999-2006 Intel Corporation. > e1000: 0000:00:0f.0: e1000_probe: (PCI:33MHz:32-bit) 00:1b:21:7c:98:53 > RTnet: registered rteth0 > e1000: rteth0: e1000_probe: Intel(R) PRO/1000 Network Connection > initializing loopback... > RTnet: registered rtlo > RTcfg: init real-time configuration distribution protocol > RTmac: init realtime media access control > RTmac/TDMA: init time division multiple access control mechanism > e1000: rteth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex > Waiting for all slaves... > > root@nfs1-webcam:~# /usr/local/rtnet/sbin/rtifconfig > rteth0 Medium: Ethernet Hardware address: 00:1B:21:7C:98:53 > IP address: 10.0.0.1 Broadcast address: 10.0.0.255 > UP BROADCAST RUNNING MTU: 1500 > > rtlo Medium: Local Loopback > IP address: 127.0.0.1 > UP LOOPBACK RUNNING MTU: 1500 > > root@nfs1-webcam:~# ifconfig vnic0 > vnic0 Link encap:Ethernet HWaddr 00:1B:21:7C:98:53 > inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MTU:1496 Metric:1 > RX packets:4 errors:0 dropped:0 overruns:0 frame:0 > TX packets:5 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:382 (382.0 B) TX bytes:642 (642.0 B) > > root@nfs1-webcam:~# cat /proc/interrupts > CPU0 > 16: 929 IPIC Level serial > 17: 39 IPIC Level > 19: 49 IPIC Level i2c-mpc > 21: 0 IPIC Level i2c-mpc > 22: 0 IPIC Level fsl_spi > 25: 2 IPIC Level phy_interrupt > 32: 2 IPIC Level eth0_g0_tx > 33: 0 IPIC Level eth0_g0_rx > 34: 0 IPIC Level eth0_g0_er > 35: 7173 IPIC Level eth1_g0_tx > 36: 9821 IPIC Level eth1_g0_rx > 37: 0 IPIC Level eth1_g0_er > 38: 101190 IPIC Level ehci_hcd:usb1 > 77: 11 IPIC Level fsl-lbc > LOC: 8868 Local timer interrupts > SPU: 1 Spurious interrupts > CNT: 0 Performance monitoring interrupts > MCE: 0 Machine check exceptions > > root@nfs1-webcam:~# cat /proc/xenomai/irq > IRQ CPU0 > 17: 290488 rteth0 > 512: 383483 [timer] > 516: 46 [virtual] > > dmegs just says the same. As soon as I stop the rtnet service on the slave, > the master is spamming TDMA errors. But that makes sense. > Checking through /var/log/messages I found in the error case: > Oct 26 15:00:07 nfs1-webcam daemon.err udevd[1107]: worker [1268] > unexpectedly returned with status 0x0100 > Oct 26 15:00:13 nfs1-webcam daemon.err udevd[1107]: worker [1268] failed > while handling '/devices/virtual/net/vnic0' > Oct 26 15:00:23 nfs1-webcam user.warn kernel: TDMA: Failed to transmit sync > mit sync frame! > > Currently, there is no further access to another host. Will try to get one > next week and check the NICs there. > > Cheers > > Am Freitag, 26. Oktober 2012 17:07 CEST, Jan Kiszka <jan.kis...@siemens.com> > schrieb: > > > That is suspicious. Could you check if the is no IRQ conflict between > > the rt-nic on some other Linux device? See /proc/interrupts and > > /proc/xenomai/irq (when the NIC is started). Also, the full dmesg log > > may reveal further details. > > > > Jan > > > > -- > > Siemens AG, Corporate Technology, CT RTC ITP SDP-DE > > Corporate Competence Center Embedded Linux > > > > > ------------------------------------------------------------------------------ > The Windows 8 Center > In partnership with Sourceforge > Your idea - your app - 30 days. Get started! > http://windows8center.sourceforge.net/ > what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ > _______________________________________________ > RTnet-users mailing list > RTnet-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/rtnet-users ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
