rtnet-users — support, discussion, and announcement list

Re: [RTnet-users] Odp: Re: RTcfg implementation issues

[Mariusz J. <mar...@wp...>]

Hi,

> >>> 1. What exactly client should do with content of Active Station field in stage 2 Initial frame? All the necessary information can be obtained through a announcement and a ready frames.
> >>
> >> Not really. For how many reply should a new client wait after sending
> >> out its announcement frame?
> > 
> > You mean, waiting for what? Let summarize negotiation procedure:
> > 1. Server send Config Stage 1.
> > 2. New client send New Announce.
> > 3. Other clients send Reply Announce -- then new client update its tables (eg. ARP).
> > 4. Server send Config State 2 -- with Active station field (I don't need it so far)
> > 5. Server send Config 2 frames, client send ACK.
> > 6. When Stage 2 will be finished, client send ready frame -- from now it is able to communicate with other nodes, if some node hasn't sent Reply Announce is not present in ARP table so write operation will fail. We know if node is ready from bit 1 of Flag field of Reply Announcement frame or from Ready frame. 
> > 
> > Have I missed something?
> 
> Hmm, don't think so. And it looks like this field is write-only in
> RTnet's RTcfg implementations as well. So it was likely added to the
> spec with something else in mind that I do not remember anymore and also
> never implemented.

Ok, I skip this field.

> > 
> >>> 2. What should happen when a client detect a inconsistent state 2 data between ack? It should wait for a number of frames given by burst rate or do something else?  
> >>
> >> What kind of inconsistency do you have in mind? In case a client
> >> receives some stage 2 configs it doesn't like, it must not ack it.
> >> Rather, it acks what it already received properly. Can be 0 as well.
> >> That shall trigger the server to retry the stage 2 configuration from
> >> that point on.
> > 
> > On this stage I don't have any particular inconsistency on my mind. I only try follow of RTnet specification. As far as I understand, client should send ACK after specified number of stage 2 configuration frames given by burs rate (value negotiated with server). For example, if burst rate is set to 2 and after first frame client detect inconsistent data, it should wait for one more frame and, then send ACK witch proper Acknowledge Length or should send ack just after detect inconsistency? 
> 
> I'm afraid this is not that precisely specified. The current
> implementation should handle and "early" ack as well, resetting the
> config offset accordingly and resuming transmission from there. So let's
> assume this was also specified. ;)

Ok, it sounds reasonable.

> > 
> >>> 3. What happen when the flag 0 (request available stage 2 configuration data from the server) in Flags field in New Announcement frame is not set and the server has stage 2 data for given client (set in server RTnet configuration file)
> >>
> >> The server should assume the client ack'ed all the stage 2 configs
> >> despite not having it sent.
> > 
> > Ok.
> > 
> >>>
> >>> 4. Why Physical Client Address field in Dead Station Frame is 32bytes long?
> >>
> >> To allow support for physical media that have longer physical addresses
> >> than Ethernet.
> > 
> > Ok, I thought so.
> > 
> >>>
> >>> And other questions from standard PC implementation (Xenomai):
> >>>
> >>> 1. Where stage 2 data are stored on client side? How client can get to these data.
> >>
> >> It's stored in RTcfg stack only briefly, dropped as soon as you
> >> extracted it via the RTcfg command line tool. That tool may dump the
> >> data to the console or into a file. See documentation.
> > 
> > Ok, I have missed this part. 
> > 
> >>>
> >>> 2. If some station stop responding (stop sending a heartbeats), is there a way to inform a application that some station is down? Or that the station is up?
> >>
> >> The information is exported via /proc on both client and server. Unless
> >> I forget something, there is no event signaling mechanism to wait on
> >> such an error via the rtcfg tool, e.g. But that would be implementable
> >> if required.
> > 
> > Do you have something special in mind. This information is present in the system, the only problem is to export it to application. If you don't mind I could try to take care of it, with a little help from your side.
> 
> Well, there could be something like "rtcfg <dev> monitor
> [event,event,...]" with one event being "node-failure". Then you will
> need to define and implement a corresponding RTcfg-config IOCTL that
> implements the actual blocking of the caller and its wakeup on the
> specified events in the kernel. The return code of the IOCTL or some
> additional data structure could provide information about the event that
> caused a wakeup. Well, that's a first, rough description if such an
> interface. What would be important is to match it against an actual use
> case, i.e. some script or application that will actually call "rtcfg
> monitor". Otherwise, we risk designing something that no one would use
> in the end. What do you have in mind here?

I though rather about application api (xenomai native, posix). So, in the first step, I should implement ioctl blocking service and something like event-info structure. Then I prepare example containing relevant use case. The "rtcfg <dev> monito [event,event,...]" is last on my TODO list. What do you think about it?

Mariusz


> Jan

Re: [RTnet-users] RTnet script not working properly after initial installation

[Jan K. <jan...@we...>]

On 2013-05-31 12:08, BOESEL Diego Fernandes wrote:
> Hello,
> 
> I am trying to install RTNet on my desktop, but I can not even make the test script (single node) work properly.
> 
> 
> Here is the output of the rtnet script:
> 
> 
> dfb@sst-desktop:/usr/local/rtnet/sbin$ sudo ./rtnet start
> ioctl: No such device
> ioctl: No such device
> ioctl: No such device
> ioctl: No such device
> ioctl (add): No such device
> vnic0: ERROR while getting interface flags: No such device
> SIOCSIFADDR: No such device
> vnic0: ERROR while getting interface flags: No such device
> SIOCSIFNETMASK: No such device
> Waiting for all slaves...ioctl: No such device
> ioctl: No such device
> 
> For the installation, I followed the procedure given in "http://www.xenomai.org/index.php/RTnet:Installation_%26_Testing", with the following exception: isntead of using
> #make gconfig
> which was giving a problem when trying to find the installation path of the RTAI (which I have set correctly), I used:
> #./configure --with-rtext=/usr/realtime --enable-r8169=yes --enable-rtcap=yes
> 
> 
> My configuration:
> Linux 2.6.32.11
> RTAI 3.8.1
> rtnet-0.9.12
> 
> 
> *** OUTPUTS ***
> 
> 
> Here is the output of the ifconfig (before disabling the eth2):
> 
> 
> dfb@sst-desktop:~$ ifconfig -a
> eth2      Link encap:Ethernet  HWaddr 20:cf:30:0e:68:e4
>           inet addr:138.131.217.137  Bcast:138.131.217.255  Mask:255.255.255.0
>           inet6 addr: fe80::22cf:30ff:fe0e:68e4/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:90 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:32 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:11523 (11.5 KB)  TX bytes:4958 (4.9 KB)
>           Interrupt:55 Base address:0xe000
> 
> lo        Link encap:Local Loopback
>           inet addr:127.0.0.1  Mask:255.0.0.0
>           inet6 addr: ::1/128 Scope:Host
>           UP LOOPBACK RUNNING  MTU:16436  Metric:1
>           RX packets:14 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0
>           RX bytes:928 (928.0 B)  TX bytes:928 (928.0 B)
> --------------------------------------------------------------------------------
> 
> Here is the output of the rtifconfig (after running the script):
> 
> 
> dfb@sst-desktop:/usr/local/rtnet/sbin$ sudo ./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)
> --------------------------------------------------------------------------------
> 
> Here is the output of the dmesg (after running the script):
> 
> 
> dfb@sst-desktop:/usr/local/rtnet/sbin$ dmesg
> [   45.033740] eth2: no IPv6 routers present
> [  495.118401] I-pipe: Domain RTAI registered.
> [  495.118406] RTAI[hal]: <3.8.1> mounted over IPIPE-NOTHREADS 2.6-03.
> [  495.118408] RTAI[hal]: compiled with gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) .
> [  495.118507] RTAI[hal]: mounted (IPIPE-NOTHREADS, IMMEDIATE (INTERNAL IRQs VECTORED), ISOL_CPUS_MASK: 0).
> [  495.118509] PIPELINE layers:
> [  495.118512] f87b5a00 9ac15d93 RTAI 200
> [  495.118514] c08a1b80 0 Linux 100
> [  495.144617] RTAI[malloc]: global heap size = 2097152 bytes, <BSD>.
> [  495.144852] RTAI[sched]: IMMEDIATE, MP, USER/KERNEL SPACE: <without RTAI OWN KTASKs>, <uses LINUX SYSCALLs>, kstacks pool size = 524288 bytes.
> [  495.144857] RTAI[sched]: hard timer type/freq = APIC/8351627(Hz); default timing: oneshot; linear timed lists.
> [  495.144860] RTAI[sched]: Linux timer freq = 250 (Hz), TimeBase freq = 2672690000 hz.
> [  495.144862] RTAI[sched]: timer setup = 999 ns, resched latency = 2944 ns.
> [  495.144863] RTAI[usi]: enabled.
> [  495.258979] RTDM started.
> [  531.737455]
> [  531.737457] *** RTnet 0.9.12 - built on May 31 2013 09:57:27 ***
> [  531.737458]
> [  531.737461] RTnet: initialising real-time networking
> [  531.793098] Initializing rt_r8169 driverinitializing loopback...
> [  531.806344] RTnet: registered rtlo
> [  531.836001] RTcfg: init real-time configuration distribution protocol
> [  531.857900] RTmac: init realtime media access control
> [  531.877503] RTmac/TDMA: init time division multiple access control mechanism
> --------------------------------------------------------------------------------
> 
> Here is the output of lsmod (after running the script):
> 
> 
> dfb@sst-desktop:/usr/local/rtnet/sbin$ lsmod
> Module                  Size  Used by
> tdma                   15897  0
> rtmac                   7550  1 tdma
> rtcfg                  39142  0
> rt_loopback             1023  1
> rt_r8169               14093  0
> rtpacket                3994  0
> rtipv4                 17650  1 rtcfg
> rtnet                  32742  7 tdma,rtmac,rtcfg,rt_loopback,rt_r8169,rtpacket,rtipv4
> rtai_netrpc            24980  0
> rtai_rtdm             211102  5 tdma,rtcfg,rt_r8169,rtpacket,rtnet
> rtai_msg               25447  0
> rtai_mbx               12587  1 rtai_netrpc
> rtai_sem               27602  6 tdma,rtcfg,rtnet,rtai_netrpc,rtai_rtdm,rtai_mbx
> rtai_fifos             22889  0
> rtai_lxrt             153141  12 tdma,rtcfg,rt_loopback,rt_r8169,rtipv4,rtnet,rtai_netrpc,rtai_rtdm,rtai_msg,rtai_mbx,rtai_sem,rtai_fifos
> rtai_hal              268201  10 tdma,rtcfg,rtnet,rtai_netrpc,rtai_rtdm,rtai_msg,rtai_mbx,rtai_sem,rtai_fifos,rtai_lxrt
> binfmt_misc             6401  1
> ppdev                   5135  0
> snd_hda_codec_realtek   201620  1
> snd_hda_intel          21627  2
> snd_hda_codec          72643  2 snd_hda_codec_realtek,snd_hda_intel
> snd_hwdep               5586  1 snd_hda_codec
> snd_pcm_oss            34521  0
> snd_mixer_oss          13719  1 snd_pcm_oss
> snd_pcm                69218  3 snd_hda_intel,snd_hda_codec,snd_pcm_oss
> snd_seq_dummy           1338  0
> snd_seq_oss            26632  0
> snd_seq_midi            4621  0
> snd_rawmidi            18931  1 snd_seq_midi
> snd_seq_midi_event      6035  2 snd_seq_oss,snd_seq_midi
> snd_seq                47288  6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event
> snd_timer              18318  2 snd_pcm,snd_seq
> snd_seq_device          5764  5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq
> agpgart                31376  0
> snd                    54318  16 snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
> soundcore               6954  1 snd
> snd_page_alloc          7172  2 snd_hda_intel,snd_pcm
> psmouse                62068  0
> asus_atk0110            8618  0
> serio_raw               4074  0
> processor              30644  0
> button                  4810  0
> joydev                  8204  0
> lp                      7092  0
> parport                32848  2 ppdev,lp
> usbhid                 35268  0
> hid                    65711  1 usbhid
> ohci1394               26849  0
> pata_jmicron            1843  0
> ahci                   31428  0
> ieee1394               80443  1 ohci1394
> mii                     4413  0
> thermal                10997  0
> --------------------------------------------------------------------------------
> 
> Does anyone know what I am doing wrong? Some hypothesis:
> - I am using just "#./configure ..." instead of "# make menuconfig" to install the library.
> - I am using r8169/rt_r8169 - is this driver working properly?

The rt_r8169 is apparently not picking up the hardware you want it to
use. You can check which driver is assigned to which PCI device using
"lspci -k". Check if the PCI-ID of the NIC you want to use is actually
supported by rt_r8169. And consider to update to 0.9.13. It came with
many updates for that driver.

Jan

Re: [RTnet-users] Odp: Re: RTcfg implementation issues

[Jan K. <jan...@we...>]

On 2013-05-31 11:12, Mariusz Janiak wrote:
> Hi Jan,
> 
>>>
>>> 1. What exactly client should do with content of Active Station field in stage 2 Initial frame? All the necessary information can be obtained through a announcement and a ready frames.
>>
>> Not really. For how many reply should a new client wait after sending
>> out its announcement frame?
> 
> You mean, waiting for what? Let summarize negotiation procedure:
> 1. Server send Config Stage 1.
> 2. New client send New Announce.
> 3. Other clients send Reply Announce -- then new client update its tables (eg. ARP).
> 4. Server send Config State 2 -- with Active station field (I don't need it so far)
> 5. Server send Config 2 frames, client send ACK.
> 6. When Stage 2 will be finished, client send ready frame -- from now it is able to communicate with other nodes, if some node hasn't sent Reply Announce is not present in ARP table so write operation will fail. We know if node is ready from bit 1 of Flag field of Reply Announcement frame or from Ready frame. 
> 
> Have I missed something?

Hmm, don't think so. And it looks like this field is write-only in
RTnet's RTcfg implementations as well. So it was likely added to the
spec with something else in mind that I do not remember anymore and also
never implemented.

> 
>>> 2. What should happen when a client detect a inconsistent state 2 data between ack? It should wait for a number of frames given by burst rate or do something else?  
>>
>> What kind of inconsistency do you have in mind? In case a client
>> receives some stage 2 configs it doesn't like, it must not ack it.
>> Rather, it acks what it already received properly. Can be 0 as well.
>> That shall trigger the server to retry the stage 2 configuration from
>> that point on.
> 
> On this stage I don't have any particular inconsistency on my mind. I only try follow of RTnet specification. As far as I understand, client should send ACK after specified number of stage 2 configuration frames given by burs rate (value negotiated with server). For example, if burst rate is set to 2 and after first frame client detect inconsistent data, it should wait for one more frame and, then send ACK witch proper Acknowledge Length or should send ack just after detect inconsistency? 

I'm afraid this is not that precisely specified. The current
implementation should handle and "early" ack as well, resetting the
config offset accordingly and resuming transmission from there. So let's
assume this was also specified. ;)

> 
>>> 3. What happen when the flag 0 (request available stage 2 configuration data from the server) in Flags field in New Announcement frame is not set and the server has stage 2 data for given client (set in server RTnet configuration file)
>>
>> The server should assume the client ack'ed all the stage 2 configs
>> despite not having it sent.
> 
> Ok.
> 
>>>
>>> 4. Why Physical Client Address field in Dead Station Frame is 32bytes long?
>>
>> To allow support for physical media that have longer physical addresses
>> than Ethernet.
> 
> Ok, I thought so.
> 
>>>
>>> And other questions from standard PC implementation (Xenomai):
>>>
>>> 1. Where stage 2 data are stored on client side? How client can get to these data.
>>
>> It's stored in RTcfg stack only briefly, dropped as soon as you
>> extracted it via the RTcfg command line tool. That tool may dump the
>> data to the console or into a file. See documentation.
> 
> Ok, I have missed this part. 
> 
>>>
>>> 2. If some station stop responding (stop sending a heartbeats), is there a way to inform a application that some station is down? Or that the station is up?
>>
>> The information is exported via /proc on both client and server. Unless
>> I forget something, there is no event signaling mechanism to wait on
>> such an error via the rtcfg tool, e.g. But that would be implementable
>> if required.
> 
> Do you have something special in mind. This information is present in the system, the only problem is to export it to application. If you don't mind I could try to take care of it, with a little help from your side.

Well, there could be something like "rtcfg <dev> monitor
[event,event,...]" with one event being "node-failure". Then you will
need to define and implement a corresponding RTcfg-config IOCTL that
implements the actual blocking of the caller and its wakeup on the
specified events in the kernel. The return code of the IOCTL or some
additional data structure could provide information about the event that
caused a wakeup. Well, that's a first, rough description if such an
interface. What would be important is to match it against an actual use
case, i.e. some script or application that will actually call "rtcfg
monitor". Otherwise, we risk designing something that no one would use
in the end. What do you have in mind here?

Jan

Re: [RTnet-users] rtdm, rt_dev_socket, pthread (Was Compiler and linker options for rtnet)

[Leopold P. A. <le...@al...>]

A Dimecres, 12 de juny de 2013, Gilles Chanteperdrix va escriure:
> On 06/12/2013 12:51 PM, Leopold Palomo-Avellaneda wrote:
> > Hi,
> > 
> > I have reviewed the code, the compiler options and I have arrived to the
> > conclusion that I was wrong and probably it was nothing about compiler
> > options.
> > 
> > However, more deeply doubts have come and I would to ask to the clever
> > people here if someone could light me. It's curious because there's
> > another person in the orocos list that has similar problems, and
> > probably our problems came from the same place.
> > 
> > The soem library, use some pthread to not block functions to send and
> > receive packets. I think that I'm having problems here. I can setup a
> > socket, but I cannot send any packet message in a simple program.
> > 
> > I got the idea of putting a:
> >    struct sched_param param = { .sched_priority = 1 };
> >    pthread_setschedparam(pthread_self(), SCHED_FIFO, &param);
> > 
> > in the send function, before rt_dev_send.
> > 
> > The raw-ethernet example use it, but if I put the same parameters I got a
> > segmentation fault, The pthread library didn't like the
> > pthread_setschedparam. I have reviewed and compiled by hand linking
> > against pthread_rt , but the same.
> > 
> > Someone have some idea to solve this?
> 
> Are you doing this from the main thread? 

yes

> If yes, what is the current
> stack size limit for this process?
> If the process is started directly
> from shell, ulimit -s should give the current stack size limit.

$ulimit -s
8192

they are ok?

Regards,

Leo
-- 
--
Linux User 152692     PGP: 0xF944807E
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [RTnet-users] rtdm, rt_dev_socket, pthread (Was Compiler and linker options for rtnet)

[Gilles C. <gil...@xe...>]

On 06/12/2013 12:51 PM, Leopold Palomo-Avellaneda wrote:

> Hi,
> 
> I have reviewed the code, the compiler options and I have arrived to the 
> conclusion that I was wrong and probably it was nothing about compiler 
> options.
> 
> However, more deeply doubts have come and I would to ask to the clever people 
> here if someone could light me. It's curious because there's another person in 
> the orocos list that has similar problems, and probably our problems came from 
> the same place.
> 
> The soem library, use some pthread to not block functions to send and receive 
> packets. I think that I'm having problems here. I can setup a socket, but I 
> cannot send any packet message in a simple program.
> 
> I got the idea of putting a:
>    struct sched_param param = { .sched_priority = 1 };
>    pthread_setschedparam(pthread_self(), SCHED_FIFO, &param);
> 
> in the send function, before rt_dev_send.
> 
> The raw-ethernet example use it, but if I put the same parameters I got a 
> segmentation fault, The pthread library didn't like the pthread_setschedparam. 
> I have reviewed and compiled by hand linking against pthread_rt , but the 
> same.
> 
> Someone have some idea to solve this?


Are you doing this from the main thread? If yes, what is the current
stack size limit for this process? If the process is started directly
from shell, ulimit -s should give the current stack size limit.


-- 
                                                                Gilles.

[RTnet-users] rtdm, rt_dev_socket, pthread (Was Compiler and linker options for rtnet)

[Leopold Palomo-A. <le...@al...>]

Hi,

I have reviewed the code, the compiler options and I have arrived to the 
conclusion that I was wrong and probably it was nothing about compiler 
options.

However, more deeply doubts have come and I would to ask to the clever people 
here if someone could light me. It's curious because there's another person in 
the orocos list that has similar problems, and probably our problems came from 
the same place.

The soem library, use some pthread to not block functions to send and receive 
packets. I think that I'm having problems here. I can setup a socket, but I 
cannot send any packet message in a simple program.

I got the idea of putting a:
   struct sched_param param = { .sched_priority = 1 };
   pthread_setschedparam(pthread_self(), SCHED_FIFO, &param);

in the send function, before rt_dev_send.

The raw-ethernet example use it, but if I put the same parameters I got a 
segmentation fault, The pthread library didn't like the pthread_setschedparam. 
I have reviewed and compiled by hand linking against pthread_rt , but the 
same.

Someone have some idea to solve this?

Thanks in advance,

Leopold



-- 
--
Linux User 152692
Catalonia

Re: [RTnet-users] RTnet script not working properly after initial installation

[BOESEL D. F. <Die...@cs...>]

Does anyone have a hint on this problem?

I noticed that my NIC is RTL8111/8168B, which will not work with rt_r8169 (even though the kernel driver in normal use is r8169). Is this right?

Another problem I see is that my NIC is in eth2, not eth0. Will RTNet work under such condition?

BR
Diego

[RTnet-users] Compiler and linker options for rtnet

[Leopold P. A. <le...@al...>]

Hi,

we are working to have something "usable" of a port of soem[1] to rtnet. Soem 
uses an standard network stack to send ethercat packets (raw ethernet 
packets).

The version we're working just have changed the "standards" calls:

#define SOCKET rt_dev_socket
#define SEND rt_dev_send
#define RECV rt_dev_recv
#define BIND rt_dev_bind
#define CLOSE rt_dev_close
#define SETSOCKOPT rt_dev_setsockopt
#define IOCTL rt_dev_ioctl

by the rtnet calls and also, the pthread calls

pthread_*

by   rt_* calls.


First of all, I would like to ask which compiler options should we put. We 
have tested xeno-config with --skin=native and --skin=posix (and both).

One thing that I don't understand is that the project compiles and link with 
both options (native and posix), the examples too. But the behavior are 
different. For example, with both, we can create a socket, and send packets but 
the program example fails with cpu exceded limit. With native options only, we 
cannot create a socket.

But sometimes, we cannot create a socket. However, the rtnet examples worked. 
I'm a bit confused. To sue it, we first load the rtnet modules:

insmod /usr/local/rtnet/modules/rtnet.ko;
insmod /usr/local/rtnet/modules/rtpacket.ko;
insmod /usr/local/rtnet/modules/rtipv4.ko;
insmod /usr/local/rtnet/modules/rtudp.ko;
#no linux standard modules loaded
insmod /usr/local/rtnet/modules/rt_e1000e.ko;
(our driver)

and up the interface;
/usr/local/rtnet/sbin/rtifconfig rteth0 up;

and after run the examples we have compiled, with the rtnet version.

Any idea what's happening here?

Regards,

Leopold


[1] http://soem.berlios.de/



-- 
--
Linux User 152692     PGP: 0xF944807E
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[RTnet-users] RTnet script not working properly after initial installation

[BOESEL D. F. <Die...@cs...>]

Hello,

I am trying to install RTNet on my desktop, but I can not even make the test script (single node) work properly.


Here is the output of the rtnet script:


dfb@sst-desktop:/usr/local/rtnet/sbin$ sudo ./rtnet start
ioctl: No such device
ioctl: No such device
ioctl: No such device
ioctl: No such device
ioctl (add): No such device
vnic0: ERROR while getting interface flags: No such device
SIOCSIFADDR: No such device
vnic0: ERROR while getting interface flags: No such device
SIOCSIFNETMASK: No such device
Waiting for all slaves...ioctl: No such device
ioctl: No such device

For the installation, I followed the procedure given in "http://www.xenomai.org/index.php/RTnet:Installation_%26_Testing", with the following exception: isntead of using
#make gconfig
which was giving a problem when trying to find the installation path of the RTAI (which I have set correctly), I used:
#./configure --with-rtext=/usr/realtime --enable-r8169=yes --enable-rtcap=yes


My configuration:
Linux 2.6.32.11
RTAI 3.8.1
rtnet-0.9.12


*** OUTPUTS ***


Here is the output of the ifconfig (before disabling the eth2):


dfb@sst-desktop:~$ ifconfig -a
eth2      Link encap:Ethernet  HWaddr 20:cf:30:0e:68:e4
          inet addr:138.131.217.137  Bcast:138.131.217.255  Mask:255.255.255.0
          inet6 addr: fe80::22cf:30ff:fe0e:68e4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:90 errors:0 dropped:0 overruns:0 frame:0
          TX packets:32 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:11523 (11.5 KB)  TX bytes:4958 (4.9 KB)
          Interrupt:55 Base address:0xe000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:14 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:928 (928.0 B)  TX bytes:928 (928.0 B)
--------------------------------------------------------------------------------

Here is the output of the rtifconfig (after running the script):


dfb@sst-desktop:/usr/local/rtnet/sbin$ sudo ./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)
--------------------------------------------------------------------------------

Here is the output of the dmesg (after running the script):


dfb@sst-desktop:/usr/local/rtnet/sbin$ dmesg
[   45.033740] eth2: no IPv6 routers present
[  495.118401] I-pipe: Domain RTAI registered.
[  495.118406] RTAI[hal]: <3.8.1> mounted over IPIPE-NOTHREADS 2.6-03.
[  495.118408] RTAI[hal]: compiled with gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) .
[  495.118507] RTAI[hal]: mounted (IPIPE-NOTHREADS, IMMEDIATE (INTERNAL IRQs VECTORED), ISOL_CPUS_MASK: 0).
[  495.118509] PIPELINE layers:
[  495.118512] f87b5a00 9ac15d93 RTAI 200
[  495.118514] c08a1b80 0 Linux 100
[  495.144617] RTAI[malloc]: global heap size = 2097152 bytes, <BSD>.
[  495.144852] RTAI[sched]: IMMEDIATE, MP, USER/KERNEL SPACE: <without RTAI OWN KTASKs>, <uses LINUX SYSCALLs>, kstacks pool size = 524288 bytes.
[  495.144857] RTAI[sched]: hard timer type/freq = APIC/8351627(Hz); default timing: oneshot; linear timed lists.
[  495.144860] RTAI[sched]: Linux timer freq = 250 (Hz), TimeBase freq = 2672690000 hz.
[  495.144862] RTAI[sched]: timer setup = 999 ns, resched latency = 2944 ns.
[  495.144863] RTAI[usi]: enabled.
[  495.258979] RTDM started.
[  531.737455]
[  531.737457] *** RTnet 0.9.12 - built on May 31 2013 09:57:27 ***
[  531.737458]
[  531.737461] RTnet: initialising real-time networking
[  531.793098] Initializing rt_r8169 driverinitializing loopback...
[  531.806344] RTnet: registered rtlo
[  531.836001] RTcfg: init real-time configuration distribution protocol
[  531.857900] RTmac: init realtime media access control
[  531.877503] RTmac/TDMA: init time division multiple access control mechanism
--------------------------------------------------------------------------------

Here is the output of lsmod (after running the script):


dfb@sst-desktop:/usr/local/rtnet/sbin$ lsmod
Module                  Size  Used by
tdma                   15897  0
rtmac                   7550  1 tdma
rtcfg                  39142  0
rt_loopback             1023  1
rt_r8169               14093  0
rtpacket                3994  0
rtipv4                 17650  1 rtcfg
rtnet                  32742  7 tdma,rtmac,rtcfg,rt_loopback,rt_r8169,rtpacket,rtipv4
rtai_netrpc            24980  0
rtai_rtdm             211102  5 tdma,rtcfg,rt_r8169,rtpacket,rtnet
rtai_msg               25447  0
rtai_mbx               12587  1 rtai_netrpc
rtai_sem               27602  6 tdma,rtcfg,rtnet,rtai_netrpc,rtai_rtdm,rtai_mbx
rtai_fifos             22889  0
rtai_lxrt             153141  12 tdma,rtcfg,rt_loopback,rt_r8169,rtipv4,rtnet,rtai_netrpc,rtai_rtdm,rtai_msg,rtai_mbx,rtai_sem,rtai_fifos
rtai_hal              268201  10 tdma,rtcfg,rtnet,rtai_netrpc,rtai_rtdm,rtai_msg,rtai_mbx,rtai_sem,rtai_fifos,rtai_lxrt
binfmt_misc             6401  1
ppdev                   5135  0
snd_hda_codec_realtek   201620  1
snd_hda_intel          21627  2
snd_hda_codec          72643  2 snd_hda_codec_realtek,snd_hda_intel
snd_hwdep               5586  1 snd_hda_codec
snd_pcm_oss            34521  0
snd_mixer_oss          13719  1 snd_pcm_oss
snd_pcm                69218  3 snd_hda_intel,snd_hda_codec,snd_pcm_oss
snd_seq_dummy           1338  0
snd_seq_oss            26632  0
snd_seq_midi            4621  0
snd_rawmidi            18931  1 snd_seq_midi
snd_seq_midi_event      6035  2 snd_seq_oss,snd_seq_midi
snd_seq                47288  6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event
snd_timer              18318  2 snd_pcm,snd_seq
snd_seq_device          5764  5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq
agpgart                31376  0
snd                    54318  16 snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
soundcore               6954  1 snd
snd_page_alloc          7172  2 snd_hda_intel,snd_pcm
psmouse                62068  0
asus_atk0110            8618  0
serio_raw               4074  0
processor              30644  0
button                  4810  0
joydev                  8204  0
lp                      7092  0
parport                32848  2 ppdev,lp
usbhid                 35268  0
hid                    65711  1 usbhid
ohci1394               26849  0
pata_jmicron            1843  0
ahci                   31428  0
ieee1394               80443  1 ohci1394
mii                     4413  0
thermal                10997  0
--------------------------------------------------------------------------------

Does anyone know what I am doing wrong? Some hypothesis:
- I am using just "#./configure ..." instead of "# make menuconfig" to install the library.
- I am using r8169/rt_r8169 - is this driver working properly?
- My network card is eth2 instead of eth0.



Diego F. Boesel, M.Sc. (Technology)
R&D Engineer
die...@cs...<mailto:die...@cs...>
T    +41 41 672 75 12
F    +41 41 672 75 00

CSEM Centre Suisse d’Electronique et de Microtechnique SA
Central Switzerland Center
Untere Gründlistr. 1  |   CH-6055 Alpnach Dorf
www.csem.ch<http://www.csem.ch/>

[RTnet-users] Odp: Re: RTcfg implementation issues

[Mariusz J. <mar...@wp...>]

Hi Jan,

> > 
> > 1. What exactly client should do with content of Active Station field in stage 2 Initial frame? All the necessary information can be obtained through a announcement and a ready frames.
> 
> Not really. For how many reply should a new client wait after sending
> out its announcement frame?

You mean, waiting for what? Let summarize negotiation procedure:
1. Server send Config Stage 1.
2. New client send New Announce.
3. Other clients send Reply Announce -- then new client update its tables (eg. ARP).
4. Server send Config State 2 -- with Active station field (I don't need it so far)
5. Server send Config 2 frames, client send ACK.
6. When Stage 2 will be finished, client send ready frame -- from now it is able to communicate with other nodes, if some node hasn't sent Reply Announce is not present in ARP table so write operation will fail. We know if node is ready from bit 1 of Flag field of Reply Announcement frame or from Ready frame. 

Have I missed something?

> > 2. What should happen when a client detect a inconsistent state 2 data between ack? It should wait for a number of frames given by burst rate or do something else?  
> 
> What kind of inconsistency do you have in mind? In case a client
> receives some stage 2 configs it doesn't like, it must not ack it.
> Rather, it acks what it already received properly. Can be 0 as well.
> That shall trigger the server to retry the stage 2 configuration from
> that point on.

On this stage I don't have any particular inconsistency on my mind. I only try follow of RTnet specification. As far as I understand, client should send ACK after specified number of stage 2 configuration frames given by burs rate (value negotiated with server). For example, if burst rate is set to 2 and after first frame client detect inconsistent data, it should wait for one more frame and, then send ACK witch proper Acknowledge Length or should send ack just after detect inconsistency? 

> > 3. What happen when the flag 0 (request available stage 2 configuration data from the server) in Flags field in New Announcement frame is not set and the server has stage 2 data for given client (set in server RTnet configuration file)
> 
> The server should assume the client ack'ed all the stage 2 configs
> despite not having it sent.

Ok.

> > 
> > 4. Why Physical Client Address field in Dead Station Frame is 32bytes long?
> 
> To allow support for physical media that have longer physical addresses
> than Ethernet.

Ok, I thought so.

> > 
> > And other questions from standard PC implementation (Xenomai):
> > 
> > 1. Where stage 2 data are stored on client side? How client can get to these data.
> 
> It's stored in RTcfg stack only briefly, dropped as soon as you
> extracted it via the RTcfg command line tool. That tool may dump the
> data to the console or into a file. See documentation.

Ok, I have missed this part. 

> > 
> > 2. If some station stop responding (stop sending a heartbeats), is there a way to inform a application that some station is down? Or that the station is up?
> 
> The information is exported via /proc on both client and server. Unless
> I forget something, there is no event signaling mechanism to wait on
> such an error via the rtcfg tool, e.g. But that would be implementable
> if required.

Do you have something special in mind. This information is present in the system, the only problem is to export it to application. If you don't mind I could try to take care of it, with a little help from your side.

Best,
Mariusz

> PS: Be warned, I've designed and implemented RTcfg a pretty long while
> ago and may no longer be 100% accurate with my answers. ;)

Ad PS. I'll be careful.

Re: [RTnet-users] RTcfg implementation issues

[Jan K. <jan...@we...>]

On 2013-05-28 18:05, Mariusz Janiak wrote:
> Hi!
> 
> During development of RTcfg layer on uP, a several questions have arisen because of lack of my understanding of the some RTcfg protocol parts. 
> 
> 1. What exactly client should do with content of Active Station field in stage 2 Initial frame? All the necessary information can be obtained through a announcement and a ready frames.

Not really. For how many reply should a new client wait after sending
out its announcement frame?

> 
> 2. What should happen when a client detect a inconsistent state 2 data between ack? It should wait for a number of frames given by burst rate or do something else?  

What kind of inconsistency do you have in mind? In case a client
receives some stage 2 configs it doesn't like, it must not ack it.
Rather, it acks what it already received properly. Can be 0 as well.
That shall trigger the server to retry the stage 2 configuration from
that point on.

> 
> 3. What happen when the flag 0 (request available stage 2 configuration data from the server) in Flags field in New Announcement frame is not set and the server has stage 2 data for given client (set in server RTnet configuration file)

The server should assume the client ack'ed all the stage 2 configs
despite not having it sent.

> 
> 4. Why Physical Client Address field in Dead Station Frame is 32bytes long?

To allow support for physical media that have longer physical addresses
than Ethernet.

> 
> And other questions from standard PC implementation (Xenomai):
> 
> 1. Where stage 2 data are stored on client side? How client can get to these data.

It's stored in RTcfg stack only briefly, dropped as soon as you
extracted it via the RTcfg command line tool. That tool may dump the
data to the console or into a file. See documentation.

> 
> 2. If some station stop responding (stop sending a heartbeats), is there a way to inform a application that some station is down? Or that the station is up?

The information is exported via /proc on both client and server. Unless
I forget something, there is no event signaling mechanism to wait on
such an error via the rtcfg tool, e.g. But that would be implementable
if required.

HTH,
Jan

PS: Be warned, I've designed and implemented RTcfg a pretty long while
ago and may no longer be 100% accurate with my answers. ;)

[RTnet-users] RTcfg implementation issues

[Mariusz J. <mar...@wp...>]

Hi!

During development of RTcfg layer on uP, a several questions have arisen because of lack of my understanding of the some RTcfg protocol parts. 

1. What exactly client should do with content of Active Station field in stage 2 Initial frame? All the necessary information can be obtained through a announcement and a ready frames.

2. What should happen when a client detect a inconsistent state 2 data between ack? It should wait for a number of frames given by burst rate or do something else?  

3. What happen when the flag 0 (request available stage 2 configuration data from the server) in Flags field in New Announcement frame is not set and the server has stage 2 data for given client (set in server RTnet configuration file)

4. Why Physical Client Address field in Dead Station Frame is 32bytes long?

And other questions from standard PC implementation (Xenomai):

1. Where stage 2 data are stored on client side? How client can get to these data. 

2. If some station stop responding (stop sending a heartbeats), is there a way to inform a application that some station is down? Or that the station is up?

That's all what bothering me at the moment. 

Best regards,
Mariusz Janiak

Re: [RTnet-users] rtnet beginner troubles

[Klemen D. <kle...@ya...>]

I see :) thank you!
Regards,
Klemen




________________________________
 From: Jan Kiszka <jan...@we...>
To: Klemen Dovrtel <kle...@ya...> 
Cc: "rtn...@li..." <rtn...@li...> 
Sent: Monday, May 27, 2013 7:49 PM
Subject: Re: rtnet beginner troubles
 

On 2013-05-27 19:09, Klemen Dovrtel wrote:
> Thank you for you reply,
> 
> I forgot to load the rtcfg module, i solved that problem. But i still can't sniff the traffic with wireshark. I did load the rtcap right after the driver. I can see the RTcap dmesg and also the rtping is responding slowly (i assume RTcap adds some delay). But i still cant see the the rteth0 (or its mirror as written in readme) with wireshark. If i understand this correctly after i load the the RTcap module, the $ifconfig should show the mirror of the rteth0 interface? A pasted the module load order, tmesg and ifconfig reply below. 
> 
> Regards,
> Klemen
> 
> 
> sudo mknod /dev/rtnet c 10 240
> 
> # unbind the NIC from the driver
> echo -n '0000:05:00.0' | sudo tee -a /sys/bus/pci/drivers/r8169/unbind
> 
> sudo insmod /usr/realtime-2.6.32-122-rtai/modules/rtai_hal.ko
> sudo insmod /usr/realtime-2.6.32-122-rtai/modules/rtai_lxrt.ko
> sudo insmod
>  /usr/realtime-2.6.32-122-rtai/modules/rtai_sem.ko
> sudo insmod /usr/realtime-2.6.32-122-rtai/modules/rtai_rtdm.ko
> 
> sudo insmod /usr/local/rtnet/modules/rtnet.ko #needed for all rtnet modules
> sudo insmod /usr/local/rtnet/modules/rt_loopback.ko
> sudo insmod /usr/local/rtnet/modules/rt_r8169.ko
> sudo insmod /usr/local/rtnet/modules/rtcap.ko #needed for sneefer
> 
> sudo insmod /usr/local/rtnet/modules/rtpacket.ko
> sudo insmod /usr/local/rtnet/modules/rtipv4.ko
> sudo insmod /usr/local/rtnet/modules/rtcfg.ko
> sudo insmod /usr/local/rtnet/modules/rtudp.ko
> 
> sudo /usr/local/rtnet/sbin/rtifconfig rtlo up 127.0.0.1
> sudo /usr/local/rtnet/sbin/rtifconfig rteth0 up 142.1.1.2 netmask 255.255.255.0
> sudo /usr/local/rtnet/sbin/rtroute solicit 142.1.1.3 dev rteth0 # Add host route using ARP
> 
> 
> 
> [   68.849874] r8169 0000:05:00.0: PCI INT A disabled
> [   68.894566] I-pipe: Domain RTAI registered.
> [   68.894584] RTAI[hal]: <3.8.1> mounted over IPIPE-NOTHREADS 2.6-03.
> [   68.894591] RTAI[hal]: compiled with gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) .
> [   68.894712] RTAI[hal]: mounted (IPIPE-NOTHREADS, IMMEDIATE (INTERNAL IRQs DISPATCHED), ISOL_CPUS_MASK: 0).
> [   68.894719] PIPELINE layers:
> [   68.894726] f9a6fe20 9ac15d93 RTAI 200
> [   68.894733] c085cb20 0 Linux 100
> [   68.960925] RTAI[malloc]: global heap size = 2097152 bytes, <BSD>.
> [   68.962170] RTAI[sched]: IMMEDIATE, MP, USER/KERNEL SPACE: <without RTAI OWN KTASKs>, kstacks pool size = 524288
>  bytes.
> [   68.962187] RTAI[sched]: hard timer type/freq = APIC/12500438(Hz); default timing: periodic; linear timed lists.
> [   68.962198] RTAI[sched]: Linux timer freq = 250 (Hz), TimeBase freq = 1800098000 hz.
> [   68.962207] RTAI[sched]: timer setup = 999 ns, resched latency = 2943 ns.
> [   68.962367] RTAI[usi]: enabled.
> [   69.047896] RTDM started.
> [   69.089874] 
> [   69.089878] *** RTnet 0.9.13 - built on Mar 12 2013 19:32:58 ***
> [   69.089881] 
> [   69.089885] RTnet: initialising real-time networking
> [   69.115100] initializing loopback...
> [   69.115125] RTnet: registered rtlo
> [   69.153813] Initializing rt_r8169 driver
> [   69.153913] rt_r8169 0000:05:00.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
> [   69.154933] rt_r8169: PCI device 0000:05:00.0: unknown chip
>  version, assuming RTL-8169
> [   69.155642] RTnet: registered rteth0
> [   69.155654] rteth0: Identified chip type is 'RTL8169'.
> [   69.155666] rteth0: rt_r8169 RTnet Gigabit Ethernet driver 2.2-04 at 0x1000, 64:70:02:12:fa:f9, IRQ 20
> [   69.163630] rteth0: Auto-negotiation Enabled.
> [   72.184219] rteth0: 1000Mbps Full-duplex operation.
> [   72.208396] RTcap: real-time capturing interface
> [   72.304630] RTcfg: init real-time configuration distribution protocol
> 
> 
> 
> $
>  ifconfig

ifconfig only lists active interfaces, ifconfig -a lists them all. Or
run ifconfig rteth0 up directly.

Jan

Re: [RTnet-users] rtnet beginner troubles

[Jan K. <jan...@we...>]

On 2013-05-27 19:09, Klemen Dovrtel wrote:
> Thank you for you reply,
> 
> I forgot to load the rtcfg module, i solved that problem. But i still can't sniff the traffic with wireshark. I did load the rtcap right after the driver. I can see the RTcap dmesg and also the rtping is responding slowly (i assume RTcap adds some delay). But i still cant see the the rteth0 (or its mirror as written in readme) with wireshark. If i understand this correctly after i load the the RTcap module, the $ifconfig should show the mirror of the rteth0 interface? A pasted the module load order, tmesg and ifconfig reply below. 
> 
> Regards,
> Klemen
> 
> 
> sudo mknod /dev/rtnet c 10 240
> 
> # unbind the NIC from the driver
> echo -n '0000:05:00.0' | sudo tee -a /sys/bus/pci/drivers/r8169/unbind
> 
> sudo insmod /usr/realtime-2.6.32-122-rtai/modules/rtai_hal.ko
> sudo insmod /usr/realtime-2.6.32-122-rtai/modules/rtai_lxrt.ko
> sudo insmod
>  /usr/realtime-2.6.32-122-rtai/modules/rtai_sem.ko
> sudo insmod /usr/realtime-2.6.32-122-rtai/modules/rtai_rtdm.ko
> 
> sudo insmod /usr/local/rtnet/modules/rtnet.ko #needed for all rtnet modules
> sudo insmod /usr/local/rtnet/modules/rt_loopback.ko
> sudo insmod /usr/local/rtnet/modules/rt_r8169.ko
> sudo insmod /usr/local/rtnet/modules/rtcap.ko #needed for sneefer
> 
> sudo insmod /usr/local/rtnet/modules/rtpacket.ko
> sudo insmod /usr/local/rtnet/modules/rtipv4.ko
> sudo insmod /usr/local/rtnet/modules/rtcfg.ko
> sudo insmod /usr/local/rtnet/modules/rtudp.ko
> 
> sudo /usr/local/rtnet/sbin/rtifconfig rtlo up 127.0.0.1
> sudo /usr/local/rtnet/sbin/rtifconfig rteth0 up 142.1.1.2 netmask 255.255.255.0
> sudo /usr/local/rtnet/sbin/rtroute solicit 142.1.1.3 dev rteth0 # Add host route using ARP
> 
> 
> 
> [   68.849874] r8169 0000:05:00.0: PCI INT A disabled
> [   68.894566] I-pipe: Domain RTAI registered.
> [   68.894584] RTAI[hal]: <3.8.1> mounted over IPIPE-NOTHREADS 2.6-03.
> [   68.894591] RTAI[hal]: compiled with gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) .
> [   68.894712] RTAI[hal]: mounted (IPIPE-NOTHREADS, IMMEDIATE (INTERNAL IRQs DISPATCHED), ISOL_CPUS_MASK: 0).
> [   68.894719] PIPELINE layers:
> [   68.894726] f9a6fe20 9ac15d93 RTAI 200
> [   68.894733] c085cb20 0 Linux 100
> [   68.960925] RTAI[malloc]: global heap size = 2097152 bytes, <BSD>.
> [   68.962170] RTAI[sched]: IMMEDIATE, MP, USER/KERNEL SPACE: <without RTAI OWN KTASKs>, kstacks pool size = 524288
>  bytes.
> [   68.962187] RTAI[sched]: hard timer type/freq = APIC/12500438(Hz); default timing: periodic; linear timed lists.
> [   68.962198] RTAI[sched]: Linux timer freq = 250 (Hz), TimeBase freq = 1800098000 hz.
> [   68.962207] RTAI[sched]: timer setup = 999 ns, resched latency = 2943 ns.
> [   68.962367] RTAI[usi]: enabled.
> [   69.047896] RTDM started.
> [   69.089874] 
> [   69.089878] *** RTnet 0.9.13 - built on Mar 12 2013 19:32:58 ***
> [   69.089881] 
> [   69.089885] RTnet: initialising real-time networking
> [   69.115100] initializing loopback...
> [   69.115125] RTnet: registered rtlo
> [   69.153813] Initializing rt_r8169 driver
> [   69.153913] rt_r8169 0000:05:00.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
> [   69.154933] rt_r8169: PCI device 0000:05:00.0: unknown chip
>  version, assuming RTL-8169
> [   69.155642] RTnet: registered rteth0
> [   69.155654] rteth0: Identified chip type is 'RTL8169'.
> [   69.155666] rteth0: rt_r8169 RTnet Gigabit Ethernet driver 2.2-04 at 0x1000, 64:70:02:12:fa:f9, IRQ 20
> [   69.163630] rteth0: Auto-negotiation Enabled.
> [   72.184219] rteth0: 1000Mbps Full-duplex operation.
> [   72.208396] RTcap: real-time capturing interface
> [   72.304630] RTcfg: init real-time configuration distribution protocol
> 
> 
> 
> $
>  ifconfig

ifconfig only lists active interfaces, ifconfig -a lists them all. Or
run ifconfig rteth0 up directly.

Jan

Re: [RTnet-users] rtnet beginner troubles

[Klemen D. <kle...@ya...>]

Thank you for you reply,

I forgot to load the rtcfg module, i solved that problem. But i still can't sniff the traffic with wireshark. I did load the rtcap right after the driver. I can see the RTcap dmesg and also the rtping is responding slowly (i assume RTcap adds some delay). But i still cant see the the rteth0 (or its mirror as written in readme) with wireshark. If i understand this correctly after i load the the RTcap module, the $ifconfig should show the mirror of the rteth0 interface? A pasted the module load order, tmesg and ifconfig reply below. 

Regards,
Klemen


sudo mknod /dev/rtnet c 10 240

# unbind the NIC from the driver
echo -n '0000:05:00.0' | sudo tee -a /sys/bus/pci/drivers/r8169/unbind

sudo insmod /usr/realtime-2.6.32-122-rtai/modules/rtai_hal.ko
sudo insmod /usr/realtime-2.6.32-122-rtai/modules/rtai_lxrt.ko
sudo insmod
 /usr/realtime-2.6.32-122-rtai/modules/rtai_sem.ko
sudo insmod /usr/realtime-2.6.32-122-rtai/modules/rtai_rtdm.ko

sudo insmod /usr/local/rtnet/modules/rtnet.ko #needed for all rtnet modules
sudo insmod /usr/local/rtnet/modules/rt_loopback.ko
sudo insmod /usr/local/rtnet/modules/rt_r8169.ko
sudo insmod /usr/local/rtnet/modules/rtcap.ko #needed for sneefer

sudo insmod /usr/local/rtnet/modules/rtpacket.ko
sudo insmod /usr/local/rtnet/modules/rtipv4.ko
sudo insmod /usr/local/rtnet/modules/rtcfg.ko
sudo insmod /usr/local/rtnet/modules/rtudp.ko

sudo /usr/local/rtnet/sbin/rtifconfig rtlo up 127.0.0.1
sudo /usr/local/rtnet/sbin/rtifconfig rteth0 up 142.1.1.2 netmask 255.255.255.0
sudo /usr/local/rtnet/sbin/rtroute solicit 142.1.1.3 dev rteth0 # Add host route using ARP



[   68.849874] r8169 0000:05:00.0: PCI INT A disabled
[   68.894566] I-pipe: Domain RTAI registered.
[   68.894584] RTAI[hal]: <3.8.1> mounted over IPIPE-NOTHREADS 2.6-03.
[   68.894591] RTAI[hal]: compiled with gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) .
[   68.894712] RTAI[hal]: mounted (IPIPE-NOTHREADS, IMMEDIATE (INTERNAL IRQs DISPATCHED), ISOL_CPUS_MASK: 0).
[   68.894719] PIPELINE layers:
[   68.894726] f9a6fe20 9ac15d93 RTAI 200
[   68.894733] c085cb20 0 Linux 100
[   68.960925] RTAI[malloc]: global heap size = 2097152 bytes, <BSD>.
[   68.962170] RTAI[sched]: IMMEDIATE, MP, USER/KERNEL SPACE: <without RTAI OWN KTASKs>, kstacks pool size = 524288
 bytes.
[   68.962187] RTAI[sched]: hard timer type/freq = APIC/12500438(Hz); default timing: periodic; linear timed lists.
[   68.962198] RTAI[sched]: Linux timer freq = 250 (Hz), TimeBase freq = 1800098000 hz.
[   68.962207] RTAI[sched]: timer setup = 999 ns, resched latency = 2943 ns.
[   68.962367] RTAI[usi]: enabled.
[   69.047896] RTDM started.
[   69.089874] 
[   69.089878] *** RTnet 0.9.13 - built on Mar 12 2013 19:32:58 ***
[   69.089881] 
[   69.089885] RTnet: initialising real-time networking
[   69.115100] initializing loopback...
[   69.115125] RTnet: registered rtlo
[   69.153813] Initializing rt_r8169 driver
[   69.153913] rt_r8169 0000:05:00.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
[   69.154933] rt_r8169: PCI device 0000:05:00.0: unknown chip
 version, assuming RTL-8169
[   69.155642] RTnet: registered rteth0
[   69.155654] rteth0: Identified chip type is 'RTL8169'.
[   69.155666] rteth0: rt_r8169 RTnet Gigabit Ethernet driver 2.2-04 at 0x1000, 64:70:02:12:fa:f9, IRQ 20
[   69.163630] rteth0: Auto-negotiation Enabled.
[   72.184219] rteth0: 1000Mbps Full-duplex operation.
[   72.208396] RTcap: real-time capturing interface
[   72.304630] RTcfg: init real-time configuration distribution protocol



$
 ifconfig
eth0      Link encap:Ethernet  HWaddr e8:40:f2:06:53:89  
          inet addr:192.168.1.13  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::ea40:f2ff:fe06:5389/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1809 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1718 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1766355 (1.7 MB)  TX bytes:268548 (268.5 KB)
          Interrupt:28
 Base address:0xe000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:42 errors:0 dropped:0 overruns:0 frame:0
          TX packets:42 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4302 (4.3 KB)  TX bytes:4302 (4.3 KB)

$ sudo ./sbin/rtifconfig
rtlo      Medium: Local Loopback
          IP address: 127.0.0.1  
          UP LOOPBACK RUNNING  MTU: 1500

rteth0    Medium: Ethernet  Hardware address: 64:70:02:12:FA:F9
          IP address: 142.1.1.2  Broadcast address: 142.1.1.255
          UP BROADCAST RUNNING  MTU:
 1500
          RX packets:5 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 
          RX bytes:1710 (1.6 Kb)  TX bytes:120 (120.0 b)






________________________________
 From: Jan Kiszka <jan...@we...>
To: Klemen Dovrtel <kle...@ya...> 
Cc: "rtn...@li..." <rtn...@li...> 
Sent: Monday, May 27, 2013 7:33 AM
Subject: Re: rtnet beginner troubles
 

On 2013-05-25 11:18, Klemen Dovrtel wrote:
> I set up two computers with rtnet and configure the network cards so that i can successfully rtping.
> 
> Then I tried sniff for data with wireshark, but when i run it, the wireshark does not detect the rteth0 network card. I have the rtcap module installed/loaded.

Does your RT-NIC work (rtifconfig etc.)? Then, rtcap has to be loaded
after that driver but before starting its interface via rtifconfig. The
rtnet start script implicitly documents the steps. And then there is
README.rtcap, of course.

> 
> 
> I also tried to test some Server Command. I tried to "rtcfg rteth0 add/server/whatever" but i get an error reply: "ioctl: Inappropriate ioctl for device".

insmod rtcfg? Again, the startup script can serve as a guide - or may
just work for you.

Jan

Re: [RTnet-users] rtnet beginner troubles

[Jan K. <jan...@we...>]

On 2013-05-25 11:18, Klemen Dovrtel wrote:
> I set up two computers with rtnet and configure the network cards so that i can successfully rtping.
> 
> Then I tried sniff for data with wireshark, but when i run it, the wireshark does not detect the rteth0 network card. I have the rtcap module installed/loaded.

Does your RT-NIC work (rtifconfig etc.)? Then, rtcap has to be loaded
after that driver but before starting its interface via rtifconfig. The
rtnet start script implicitly documents the steps. And then there is
README.rtcap, of course.

> 
> 
> I also tried to test some Server Command. I tried to "rtcfg rteth0 add/server/whatever" but i get an error reply: "ioctl: Inappropriate ioctl for device".

insmod rtcfg? Again, the startup script can serve as a guide - or may
just work for you.

Jan

[RTnet-users] rtnet beginner troubles

[Klemen D. <kle...@ya...>]

I set up two computers with rtnet and configure the network cards so that i can successfully rtping.

Then I tried sniff for data with wireshark, but when i run it, the wireshark does not detect the rteth0 network card. I have the rtcap module installed/loaded.


I also tried to test some Server Command. I tried to "rtcfg rteth0 add/server/whatever" but i get an error reply: "ioctl: Inappropriate ioctl for device".

Can someone please give me some hints about the possible problem.

Regards,
Klemen

[RTnet-users] wireshark rtnet v2 communication example

[Klemen D. <kle...@ya...>]

Hello everybody,

Is there a rtnet V2 communication example which can be loaded to wireshark? I found one at http://www.erwinrol.com/wireshark/, but this one is uses rtnet V1, which is not used any more.

Regards,
Klemen

Re: [RTnet-users] RTnet testing

[Klemen D. <kle...@ya...>]

Thank you Jan, that solved both problems :)
Regards,
Klemen




________________________________
 From: Jan Kiszka <jan...@we...>
To: Klemen Dovrtel <kle...@ya...> 
Cc: "rtn...@li..." <rtn...@li...> 
Sent: Thursday, May 16, 2013 9:03 AM
Subject: Re: RTnet testing
 

On 2013-05-16 08:21, Klemen Dovrtel wrote:
> Hello everybody,
> 
> I successfully tested the rtnet on 100Mbit network interface card that used 8139too and 8139cp modules. I removed that modules and installed the rtnet substitute as suggested at Rtnet wiki (http://www.xenomai.org/index.php/RTnet:Installation_%26_Testing)
> 
> 1. Now i would like to test the 1Gbit RTL-8169 Gigabit Ethernet card. But now i have a problem removing r8169 and installing rt_r8169 because there is another network interface card in the motherboard that also uses the r8169 module:
> 
> lspco -nnk:
> 
> 1:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
> RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 
> 06)
>     Kernel driver in use: r8169
>     Kernel modules: r8169
> 05:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
 RTL-8169 Gigabit Ethernet [10ec:8169] (rev 10)
>     Kernel driver in use: r8169
>     Kernel modules: r8169
> 
> When i remove the r8169 module both network cards go down. Any idea how can i remove ther8169 and install the rt_r8169for 1Gbit Ethernet card only?

Check /sys/bus/pci/drivers/r8169/unbind. Echoing, e.g., "0000:05:00.0"
to that file will unbind the second adapter from the driver, allowing
the RTnet driver to pick it up (on insmod or via "echo 0000:05:00.0 >
/sys/bus/pci/drivers/rt_r8169/bind").

> 
> 2. I also tried to install thert_r8169 after removing the r8169 but afterwards i could not find any rteth interface. I tried to "/usr/local/rtnet/sbin/rtifconfig rteth0 up 142.1.1.1 netmask 255.255.255.0" with different rteth0..5 but all replied there is no such rteth interface.
> 
> lspco -nnk:
> 1:00.0 Ethernet controller [0200]: Realtek
 Semiconductor Co., Ltd. 
> RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 
> 06)
>     Kernel modules: r8169
> 05:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet [10ec:8169] (rev 10)
>     Kernel driver in use: rt_r8169
>     Kernel modules: r8169
> 
> Any idea what could be wrong? How can i find the rteth interface of my rtnet driver?

Check what dmesg reports, check /proc/rtnet/devices. Does /dev/rtnet
exist when you want to call rtifconfig?

Jan

Re: [RTnet-users] RTnet testing

[Jan K. <jan...@we...>]

On 2013-05-16 08:21, Klemen Dovrtel wrote:
> Hello everybody,
> 
> I successfully tested the rtnet on 100Mbit network interface card that used 8139too and 8139cp modules. I removed that modules and installed the rtnet substitute as suggested at Rtnet wiki (http://www.xenomai.org/index.php/RTnet:Installation_%26_Testing)
> 
> 1. Now i would like to test the 1Gbit RTL-8169 Gigabit Ethernet card. But now i have a problem removing r8169 and installing rt_r8169 because there is another network interface card in the motherboard that also uses the r8169 module:
> 
> lspco -nnk:
> 
> 1:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
> RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 
> 06)
>     Kernel driver in use: r8169
>     Kernel modules: r8169
> 05:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet [10ec:8169] (rev 10)
>     Kernel driver in use: r8169
>     Kernel modules: r8169
> 
> When i remove the r8169 module both network cards go down. Any idea how can i remove ther8169 and install the rt_r8169for 1Gbit Ethernet card only?

Check /sys/bus/pci/drivers/r8169/unbind. Echoing, e.g., "0000:05:00.0"
to that file will unbind the second adapter from the driver, allowing
the RTnet driver to pick it up (on insmod or via "echo 0000:05:00.0 >
/sys/bus/pci/drivers/rt_r8169/bind").

> 
> 2. I also tried to install thert_r8169 after removing the r8169 but afterwards i could not find any rteth interface. I tried to "/usr/local/rtnet/sbin/rtifconfig rteth0 up 142.1.1.1 netmask 255.255.255.0" with different rteth0..5 but all replied there is no such rteth interface.
> 
> lspco -nnk:
> 1:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
> RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 
> 06)
>     Kernel modules: r8169
> 05:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet [10ec:8169] (rev 10)
>     Kernel driver in use: rt_r8169
>     Kernel modules: r8169
> 
> Any idea what could be wrong? How can i find the rteth interface of my rtnet driver?

Check what dmesg reports, check /proc/rtnet/devices. Does /dev/rtnet
exist when you want to call rtifconfig?

Jan

[RTnet-users] RTnet testing

[Klemen D. <kle...@ya...>]

Hello everybody,

I successfully tested the rtnet on 100Mbit network interface card that used 8139too and 8139cp modules. I removed that modules and installed the rtnet substitute as suggested at Rtnet wiki (http://www.xenomai.org/index.php/RTnet:Installation_%26_Testing)

1. Now i would like to test the 1Gbit RTL-8169 Gigabit Ethernet card. But now i have a problem removing r8169 and installing rt_r8169 because there is another network interface card in the motherboard that also uses the r8169 module:

lspco -nnk:

1:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 
06)
    Kernel driver in use: r8169
    Kernel modules: r8169
05:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet [10ec:8169] (rev 10)
    Kernel driver in use: r8169
    Kernel modules: r8169

When i remove the r8169 module both network cards go down. Any idea how can i remove ther8169 and install the rt_r8169for 1Gbit Ethernet card only?

2. I also tried to install thert_r8169 after removing the r8169 but afterwards i could not find any rteth interface. I tried to "/usr/local/rtnet/sbin/rtifconfig rteth0 up 142.1.1.1 netmask 255.255.255.0" with different rteth0..5 but all replied there is no such rteth interface.

lspco -nnk:
1:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 
06)
    Kernel modules: r8169
05:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet [10ec:8169] (rev 10)
    Kernel driver in use: rt_r8169
    Kernel modules: r8169

Any idea what could be wrong? How can i find the rteth interface of my rtnet driver?

Best Regards,
Klemen

Re: [RTnet-users] Will RTnet be useful and necessary for my project?

[Jan K. <jan...@we...>]

On 2013-05-02 00:15, Sebastian Pavez wrote:
> Hi everyone,
> 
> I haven't install RTnet yet because I wanna to make sure if this will 
> help me. First of all a little contextualization:
> I'm working with Xenomai on a educational project. The idea is quite 
> simple, develop a control system (for position and velocity control of a 
> DC motor) and study his performance with a "perturbation" task (wich is 
> no more than a "for" loop to increase the execution time of this task), 
> working with the highest priority for the perturbation and show how the 
> situation is improved when the priority is higher for the control task. 
> Even if it seems easy, it hadn't been for me because I don't have much 
> background with linux, RT issues and only a little bit with C languaje. 
> But I managed to make it work.
> 
> Now the idea is to develop a remote lab wich could be controlled via EJS 
> (Easy Java Simulations). My problem is with the communication, I have an 
> operative example of a TCP/IP server on C and the client on Java (EJS). 
> But my doubts are with the real time issues, I don't know how to connect 
> the server with the control task (I'm thinking on shared memory). That's 
> why my teacher asked in the Xenomai mail list if the above is possible 
> and the answer he get was: use RTnet ...
> 
> Now, is it that true? I mean, How do I do that? I have to create the 
> server like another thread in the program that already have the control 
> and perturbation threads?
> Is there any problems if the client is not a real time task? I would 
> have to make some serious modifications to the client I already have in 
> Java? If it possible, somebody have some information to start with? I 
> already saw that you have an example for a tcp server.

Is the Java application part of your control loop (physical process ->
sensor -> control algorithm -> actuator -> physical process)? If so, you
would first of all have to pick real-time Java VM before thinking about
real-time communication. But that's asking for complexity you likely do
not want for such a simple task.

Writing some non-RT configuration and monitoring front-end in Java is
fine, but the actual control task is better done in C (or C++ if you
like). The RT process containing the control task could then have a
another thread, low priority, that does the non-RT communication with
the front-end via TCP and transfers any parameter updates to the RT task
(lock-free or synchronized with a compatible locking mechanism). That's
the standard design pattern for real-time control applications.

Jan

Re: [RTnet-users] Install RTnet

[Thanasis <tha...@gm...>]

PS Because I m new to ubuntu i would like to ask for helping enabling rtdm 
too. Thanks

Re: [RTnet-users] Install RTnet

[WIEGAND R. <Ral...@he...>]

Hello,

do you have RTDM enabled in the Rtai-configuration ?





Hexagon Metrology GmbH
Siegmund-Hiepe-Str. 2-12
35578 Wetzlar
Deutschland

Phone: +49 6441 207-410
Fax: +49 6441 207-387

E-Mail: Ral...@he... 


Hauptgeschäftsführer: Holger Fritze
Geschäftsführer: Per Holmberg - Arno Seuren - Michael Rosenbruch
Amtsgericht Wetzlar, HRB 1201


-----Ursprüngliche Nachricht-----
Von: Thanasis [mailto:tha...@gm...] 
Gesendet: Mittwoch, 8. Mai 2013 11:51
An: rtn...@li...
Betreff: [RTnet-users] Install RTnet

Hi,
I am trying to install Rtnet 0.9.13 on ubuntu 10.04 with kernel 2.6.32 and 
RTAI 3.8.1 and during the ./configure execution an error occurs:
checking for RTDM skin... configure: error: *** Please enable RTDM skin

I have searched the web for a solution but I have found nothing that could 
really help me. I would like to ask for your help if it possible to tell me 
what is going wrong and how I could fix it.

Thank you in advance,
Athanasatos Thanasis



------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________
RTnet-users mailing list
RTn...@li...
https://lists.sourceforge.net/lists/listinfo/rtnet-users

[RTnet-users] Install RTnet

[Thanasis <tha...@gm...>]

Hi,
I am trying to install Rtnet 0.9.13 on ubuntu 10.04 with kernel 2.6.32 and 
RTAI 3.8.1 and during the ./configure execution an error occurs:
checking for RTDM skin... configure: error: *** Please enable RTDM skin

I have searched the web for a solution but I have found nothing that could 
really help me. I would like to ask for your help if it possible to tell me 
what is going wrong and how I could fix it.

Thank you in advance,
Athanasatos Thanasis