[EMAIL PROTECTED] wrote: > 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...). > I'm working on a laptop so I don't know if it's possible to switch the PCI device (not going to try it). I also changed some setting in the bios but it didn't work but it's not a problem anymore. I ran my applications in the command-line but 1 question remains to me, why can I run the programms in the command-line (no IRQ-conflicts) and not in KDE, is it that KDE uses some device that you won't need in the command-line ?
Thanks for all your help, Jeroen >> >>>> 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 ------------------------------------------------------------------------- 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
