matrix_df hotmail wrote: > Hello > >> From: Jan Kiszka <[EMAIL PROTECTED]> >> To: [EMAIL PROTECTED] >> CC: rtnet-users@lists.sourceforge.net >> Subject: Re: [RTnet-users] RTnet and RTAI 3.3 master and slave problem >> Date: Wed, 15 Mar 2006 17:27:18 +0100 >> >> matrix_df hotmail wrote: >> > Hello >> > >> > rtcfg problem >> > Master and slave do not find each other! >> > >> > Master sends RTmac broadcast packets, but slave does not respond. >> > >> > With Intel 8257/8/9 cards the system CRASHES !!!!! >> >> During cleanup or already during startup? In the latter case, please >> check for potential IRQ conflicts between the RT-NIC and some Linux >> devices. They must be resolved first. > > During startup. > I have not checked for IRQ conflicts when using the Intel 8257/8/9 cards. > When using the realtek 8139 there seem to be no conflict. > [EMAIL PROTECTED] rtnet]# cat /proc/interrupts > CPU0 > 0: 66293852 XT-PIC timer, rtai_jif_chk > 1: 42863 XT-PIC i8042 > 2: 0 XT-PIC cascade > 8: 1 XT-PIC rtc > 9: 15354264 XT-PIC eth0, [EMAIL PROTECTED]:0000:01:05.0 > 10: 244259 XT-PIC eth1 > 12: 810417 XT-PIC i8042 > 14: 214209 XT-PIC ide0 > 15: 32 XT-PIC ide1 > NMI: 0 > ERR: 0 > > and the realtek 8139 card on master uses IRQ 11.
As long as you just switch the cards in the same PCI slot, the same IRQ should get assigned. >>... >> > Waiting for all slaves...RTcfg: rtcfg_do_main_event() rtdev=1, >> > event=RTCFG_CMD_WAIT, state=RTCFG_MAIN_SERVER_RUNNING >> > RTcfg: error -105 while sending stage 1 frame >> > RTcfg: error -105 while sending stage 1 frame >> > RTcfg: error -105 while sending stage 1 frame >> > RTcfg: error -105 while sending stage 1 frame >> >> Link problem? This error is reported when the NIC failed to transmit >> frames queued by RTcfg so that the latter ran out of buffers. This might >> be due to physical transmission problems, or there is no fitting TDMA >> slot available (shouldn't be the case when using the standard configs). > > I am using the standard script. (only master and slave adopted) > >> Please check /proc/rtnet/rtmac/tdma_slots. BTW, further state >> information about RTcfg is available via /proc/rtnet/rtcfg/rteth0/*. > > [EMAIL PROTECTED] sjoc]# cat /proc/rtnet/rtcfg/rteth0/state > state: 1 (SERVER_RUNNING) > flags: 00010000 > other stations: 1 > stations found: 0 > stations ready: 0 > configured clients: 0 > burstrate: 4 > heartbeat period: 1000 ms > > [EMAIL PROTECTED] rtnet]# cat /proc/rtnet/rtmac/tdma_slots > Interface Slots (id[->joint]:offset:phasing/period:size) > rteth0 0:0:1/1:1500 > All fine. >>... >> > ########################################################### >> > >> > see attached ethereal file for tdma, tdmac packets >> >> On which box did you capture, master or slave? Or on an independent >> sniffer box? Only the sync messages are included in the dump, no RTcfg >> frame which should pop up at least once per second. Either you skipped >> them accidentally (the dump includes only 20 ms), or the RTcfg service >> has some real problem here. > > I just shortend the capturing, because the sync is the only message. > Messages were captured on master, but also verified by a third computer > (sniffer). > There are no "RTcfg frames" !! > > Who should send the RTcfg frames (invitation), the master or? > > So what should I check next? > What are about kernel configuration options, ACPI, .....!! ACPI should be off, though this may "only" increase latencies when remaining on. > > Is there a reference system which works? > Perhaps a system with Xenomai. > (Please attach all vital information, kernel, xenomai version, > configuration) Although I was recently flamed for suggesting this, it could help to narrow down where to look next. Our latest successful setups are based on Xenomai 2.1, kernel 2.6.15.x (x86), and RTnet SVN. I have one RTAI 3.3 setup on my notebook, and I could also check later if it spits out RTcfg frames when running a RTnet master. Jan
signature.asc
Description: OpenPGP digital signature
