Jan Kiszka wrote: > Willems, J.J.P.A. schrieb: > > Karl Reichert wrote: > >> Willems, J.J.P.A. wrote: > >>> Hi, > >>> > >>> I'm trying to set up a direct connection between two notebooks but > >>> the don't see each other. The master is waiting for the slaves and > >>> the slave hangs at stage 1: searching the master. After stopping the > >>> waiting, rtpinging doesn't work either. > >>> > >>> I'm using a IBM T42 notebook as the master with the e1000 module and > >>> a Asus A6000 as the slave with the r8169 module. > >>> > >>> I'm using linux 2.6.19.7, Xenomai 2.3.1 and Rtnet 0.9.9 on both. > >>> Pinging each other non-real time works. > >>> > >>> > >>> Some detailed info for the master: > >>> > >>> ## rtnet.conf > >>> # RT-NIC driver > >>> RT_DRIVER="rt_e1000" > >>> #RT_DRIVER_OPTIONS="cards=1,0,0,0" > >>> RT_DRIVER_OPTIONS="" > >>> IPADDR="10.0.0.1" > >>> NETMASK="" > >>> TDMA_MODE="master" > >>> # Master parameters > >>> # Simple setup: List of TDMA slaves > >>> TDMA_SLAVES="10.0.0.2" > >>> > >>> Dmesg in another console returns: "TDMA: Failed to transmit sync > >>> frame!" > >>> > >> Then of course your slave is waiting forever. It never get's any Sync > >> frame from master. I have the same network card for my master, and > >> when it fails to transmit sync frame, because cable is broken or not > >> connected, I also get a message from watchdog (Tx_unit hang). Do you > >> also get this message? I only get it when working on console > >> (Ctrl-Alt-F1). Try it out ... > >> > > > > I tried it in Ctrl+Alt+F1 but I don't see anything because I only get > > 'TDMA: Failed to transmit sync frame!' at the master's side. > > I'm sure the cable is ok and connected because non-realtime pinging > > works. > > If the NIC happens to share an IRQ with some Linux device, the conflict > might be detect and the related line be disabled. The consequence would > be that you will not be able to release transmission buffers and soon > run into such messages. > > Try to test your link first with a manual setup as described in the > readme or on the homepage. That way you control the traffic and have a > chance to immediately see what happens on the kernel console. > > > > > But I switched the master and slave. They both are again going to > > wait/search each other (in ctrl+alt+f1). > > When I run dmesg in f2 I get for the master (over and over again during > > the wait for slaves) : > > "r8169: rt18169_start_xmit: TX len = 60, skb -> len = 42, > > eth_proto=9021" > > That message storm is related to "#define RTL8169_DEBUG" in rt_r8169.c. > You may want to try to disable this line. > > Note that this driver is officially still in experimental state as no > one yet reported that it is working flawlessly, and I don't have the > hardware to test. > > Jan I do use the rt_e1000 with an Intel NIC and it works fine for me. Only problem I faced until now are an IRQ problem and big master jitter with cycle length 1 second (both already reported on this list).
Karl -- von Karl Reichert NEU! +++ GMX empfiehlt DSL-Komplettpaket von 1&1 +++ Surfen und Telefonieren!*: http://www.gmx.net/de/go/dsl ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
