Hi Jan,

    Actually, blocked = sometimes whole system freezes, but sometimes  
only the shell is affected. So it's very confusing. This only happens  
by using tdmacfg, the slave is waiting for something never received,  
so maybe the timeout is not configured ?

    With Wireshark, I did some monitoring from packets traffic tests,  
using xenomai/native/examples/, we can notice ARP and ICMP packets  
working well. However, none of UDP or TCP could be traced (surely some  
problems remains in af_packet.c ?) But how to know what is the bug ?

    I include some logs below, maybe there is something lacking ?

> -lsmod

r...@mbs270:/var/tmp$ lsmod
Module                  Size  Used by
rtudp                   9196  0
rtcfg                  47900  0
tdma                   18312  0
rtmac                  11172  1 tdma
rt_dm9000              10224  0
rt_loopback             2504  1
rtpacket                5708  0
rtipv4                 22744  2 rtudp,rtcfg
rtnet                  40080  8  
rtudp,rtcfg,tdma,rtmac,rt_dm9000,rt_loopback,rtpacket,rtipv4


> -rtifconfig

r...@mbs270:/var/tmp$ rtifconfig
rtlo      Medium: Local Loopback
           IP address: 127.0.0.1
           UP LOOPBACK RUNNING  MTU: 1500
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

rteth0    Medium: Ethernet  Hardware address: 00:14:2D:00:01:02
           IP address: 10.0.0.2  Broadcast address: 10.255.255.255
           UP BROADCAST RUNNING  MTU: 1536
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)


> -rtroute
r...@mbs270:/var/tmp$ rtroute
Host Routing Table
Hash    Destination     HW Address              Device
01      10.0.0.1        00:14:2D:00:01:01       rteth0
01      127.0.0.1       00:00:00:00:00:00       rtlo
02      10.0.0.2        00:00:00:00:00:00       rtlo
0F      10.0.0.15       00:02:B3:A7:EF:EB       rteth0
3F      10.255.255.255  FF:FF:FF:FF:FF:FF       rteth0


> -rtping 127.0.0.1
r...@mbs270:/var/tmp$ rtping 127.0.0.1
RTnet: main(). ipv4_cmd : 0x11c18
Real-time PING 127.0.0.1 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 time=73.5 us
64 bytes from 127.0.0.1: icmp_seq=2 time=74.5 us

> dmesg
<4>[ 1240.305593]
<4>[ 1240.305626] *** RTnet 0.9.12 - built on Sep 16 2010 10:49:14 ***
<4>[ 1240.305642]
<4>[ 1240.305672] RTnet: initialising real-time networking
<4>[ 1240.512230] initializing loopback...
<4>[ 1240.512400] RTnet: registered rtlo
<6>[ 1240.582634] dm9000 Real Time Ethernet Driver, V0.2
<4>[ 1240.634743] RTnet: registered rteth0
<4>[ 1240.634819] rteth0: dm9000e at c4934000,c4938004 IRQ 178 MAC:  
00:14:2d:00:01:02 (parameter)
<4>[ 1240.723960] RTmac: init realtime media access control
<4>[ 1240.791241] RTmac/TDMA: init time division multiple access  
control mechanism
<4>[ 1240.878283] RTcfg: init real-time configuration distribution protocol



Jan Kiszka <jan.kis...@web.de> a écrit :

> Am 17.09.2010 09:38, Michel He wrote:
>> Ok, actually I try to decompose rtnet script. so I load step by step
>> modules and make initialization of rtroute. the tdma configuration in
>> slave has blocked the entire system. in the master side it seems ok.
>>
>> in slave side:
>> cd /usr/rtnet/modules/
>> insmod rtnet.ko
>> insmod rtipv4.ko
>> insmod rtpacket.ko
>> insmod rt_loopback.ko
>> insmod rt_dm9000.ko mac_addr=0x00,0x14,0x2D,0x00,0x01,0x02
>> insmod rtmac.ko
>> insmod tdma.ko
>> insmod rtcfg.ko
>> insmod rtudp.ko
>>
>> rtifconfig rteth0 up 10.0.0.2
>> rtifconfig rtlo up 127.0.0.1
>> #10.0.0.1 is master
>> #rtroute add 10.0.0.1 00:14:2D:00:01:01 dev rteth0
>> #10.0.0.2 is slave
>> rtroute add 10.0.0.2 00:14:2D:00:01:02 dev rteth0
>>
>> #slave
>> tdmacfg rteth0 slave
>> tdmacfg rteth0 slot 0 400
>> #blocked system
>
> Just re-reading this: What do you mean with "blocked"? The whole system
> is unresponsive it any input, including console etc.? Then your driver
> likely caused a crash or IRQ storm. You need to debug this, before
> understanding and fixing that issue looking at effects at higher levels
> is pointless.
>
> Jan
>
>



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users

Reply via email to