[EMAIL PROTECTED] 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. > I don't know exactly which method you meant but using rtnet start (after ifconfig down and rmmod rt_module) didn't work but I manually started everything like this --- ifconfig eth0 down rmmod e1000 insmod rtnet.ko insmod rtipv4.ko insmod rtpacket.ko insmod rt_loopback.ko insmod rt_e1000.ko ifconfig rteth0 up 10.0.0.2 rtroute add 10.0.0.1 <target hw-address> dev rteth0 --- If I start rtnet up in this way in the commandline (ctrl alt f1) I can rtping the other notebook (and back), getting around 30 us. But when I try this method using the console in kdm it doesn't work, when I'm at the ifconfig rthet0 up 10.0.0.2 part, I get: Xenomai: xnintr_irq_handler: IRQ 11 not handled. Disabling IRQ Line.
>> >> 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 disabled the line and don't get the message anymore. Thanks, Jeroen ------------------------------------------------------------------------- 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
