Karl Reichert wrote: > 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).
Nope, this issue is first of all about the r8169. The e1000 is know to work. Thanks anyway, Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- 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
