Willems, J.J.P.A. wrote: > [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.
And that's precisely the message I was expecting: You are facing an IRQ conflict between the RT-NIC and some Linux-managed device. Try to look closer at the kernel logs, there should be some reports of the PCI subsystem when you start up the NIC that it shares the IRQ with some other PCI device. Use lspci e.g. to find out which one, maybe you can disable it. Otherwise, flipping the NIC's PCI slot may help (unless someone soldered it onto the board or baked it into the chipset...). > >>> 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. That message was only a symptom of the issue above. Due to the conflict, the IRQ line was disabled, thus the NIC become inoperational and queues overflew. > > Thanks, > Jeroen 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
