Willems, J.J.P.A. wrote: > [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.
Don't understand: It solved your problem magically? > 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 ? The device that shares the IRQ with your NIC is probably the graphic adapter. As long as X is unused, you don't get interrupts, thus Xenomai doesn't complain. So, unless you somehow convinced your BIOS to shuffle the NIC or graphic IRQ a bit around, you are doomed to leave any graphic off while running RTnet. There exist workaround concepts for otherwise unresolvable scenarios (One day I will write a FAQ entry about this...), but that would at least involve writing a special RT-driver stub for your graphic adapter so that IRQ sharing can be resolve in deterministic Xenomai context. 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
