rtnet-developers — development-related list

Re: [RTnet-developers] RTnet 0.9.12 partly not up to date

[Sebastian S. <sm...@rt...>]

Jan Kiszka wrote:
> Sebastian Smolorz wrote:
> > Hi Jan,
> >
> > something went wrong with the latest stable  release - e.g. in the
> > documentation directory, where README.tcp,  README.eth1394 and
> > README.gigabit are missing, see
> >
> > http://www.rts.uni-hannover.de/rtnet/lxr/source/Documentation/
> 
> Yep, lacking dist rules. The first one is new to the club, the other two
> were broken before.
> 
> Still, nothing should be missing that is relevant for building the code.
> Did you find more discrepancies?

No I didn't. But the missing README.tcp could leave people helpless who 
download 0.9.12 and want to try out RT-TCP.

-- 
Sebastian

Re: [RTnet-developers] RTnet 0.9.12 partly not up to date

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

Sebastian Smolorz wrote:
> Hi Jan,
> 
> something went wrong with the latest stable  release - e.g. in the 
> documentation directory, where README.tcp,  README.eth1394 and 
> README.gigabit are missing, see
> 
> http://www.rts.uni-hannover.de/rtnet/lxr/source/Documentation/
> 

Yep, lacking dist rules. The first one is new to the club, the other two
were broken before.

Still, nothing should be missing that is relevant for building the code.
Did you find more discrepancies?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[RTnet-developers] RTnet 0.9.12 partly not up to date

[Sebastian S. <sm...@rt...>]

Hi Jan,

something went wrong with the latest stable  release - e.g. in the 
documentation directory, where README.tcp,  README.eth1394 and 
README.gigabit are missing, see

http://www.rts.uni-hannover.de/rtnet/lxr/source/Documentation/

-- 
Sebastian

Re: [RTnet-developers] [PATCH] Make loading of RT protocols configurable

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

Sebastian Smolorz wrote:
> With splitting off UDP support from the rtipv4 kernel module and the
> advent of RT-TCP RTnet now supports three distinct protocols: packet,
> udp and tcp.
> 
> This patch introduces a new variable in rtnet.conf: RT_PROTOCOLS. It
> is set to "packet udp" by default. The rtnet loading script takes care
> of loading the desired protocol drivers.
> 
> Signed-off-by: Sebastian Smolorz <sm...@rt...>

Applied, thanks again!

Jan

> ---
>  tools/rtnet.conf.in |    3 +++
>  tools/rtnet.in      |   12 +++++++++---
>  2 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/rtnet.conf.in b/tools/rtnet.conf.in
> index 28a5eae..32f384d 100644
> --- a/tools/rtnet.conf.in
> +++ b/tools/rtnet.conf.in
> @@ -29,6 +29,9 @@ NETMASK=""
>  # Start realtime loopback device ("yes" or "no")
>  RT_LOOPBACK="yes"
>  
> +# Use the following RTnet protocol drivers
> +RT_PROTOCOLS="udp packet"
> +
>  # Start capturing interface ("yes" or "no")
>  RTCAP="no"
>  
> diff --git a/tools/rtnet.in b/tools/rtnet.in
> index 251fada..5f797a6 100755
> --- a/tools/rtnet.in
> +++ b/tools/rtnet.in
> @@ -33,9 +33,12 @@ EOF
>  init_rtnet() {
>      insmod $RTNET_MOD/rtnet$MODULE_EXT >/dev/null || exit 1
>      insmod $RTNET_MOD/rtipv4$MODULE_EXT >/dev/null || exit 1
> -    insmod $RTNET_MOD/rtpacket$MODULE_EXT >/dev/null || exit 1
>      insmod $RTNET_MOD/$RT_DRIVER$MODULE_EXT $RT_DRIVER_OPTIONS >/dev/null || exit 1
>  
> +    for PROTOCOL in $RT_PROTOCOLS; do
> +        insmod $RTNET_MOD/rt$PROTOCOL$MODULE_EXT >/dev/null || exit 1
> +    done
> +
>      if [ $RT_LOOPBACK = "yes" ]; then
>          insmod $RTNET_MOD/rt_loopback$MODULE_EXT >/dev/null || exit 1
>      fi
> @@ -307,7 +310,7 @@ case "$1" in
>          $RTIFCONFIG rteth0 down 2>/dev/null
>          $RTIFCONFIG rtlo down 2>/dev/null
>  
> -        rmmod tdma rtmac rtcfg rtcap rt_loopback $RT_DRIVER rtpacket rtipv4 rtnet 2>/dev/null
> +        rmmod tdma rtmac rtcfg rtcap rt_loopback $RT_DRIVER rtpacket rtudp rttcp rtipv4 rtnet 2>/dev/null
>          ;;
>  
>      master)
> @@ -329,7 +332,10 @@ case "$1" in
>      loopback)
>          insmod $RTNET_MOD/rtnet$MODULE_EXT >/dev/null || exit 1
>          insmod $RTNET_MOD/rtipv4$MODULE_EXT >/dev/null || exit 1
> -        insmod $RTNET_MOD/rtpacket$MODULE_EXT >/dev/null || exit 1
> +
> +        for PROTOCOL in $RT_PROTOCOLS; do
> +            insmod $RTNET_MOD/rt$PROTOCOL$MODULE_EXT >/dev/null || exit 1
> +        done
>  
>          insmod $RTNET_MOD/rt_loopback$MODULE_EXT >/dev/null || exit 1
>  

[RTnet-developers] [PATCH] Make loading of RT protocols configurable

[Sebastian S. <sm...@rt...>]

With splitting off UDP support from the rtipv4 kernel module and the
advent of RT-TCP RTnet now supports three distinct protocols: packet,
udp and tcp.

This patch introduces a new variable in rtnet.conf: RT_PROTOCOLS. It
is set to "packet udp" by default. The rtnet loading script takes care
of loading the desired protocol drivers.

Signed-off-by: Sebastian Smolorz <sm...@rt...>
---
 tools/rtnet.conf.in |    3 +++
 tools/rtnet.in      |   12 +++++++++---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/tools/rtnet.conf.in b/tools/rtnet.conf.in
index 28a5eae..32f384d 100644
--- a/tools/rtnet.conf.in
+++ b/tools/rtnet.conf.in
@@ -29,6 +29,9 @@ NETMASK=""
 # Start realtime loopback device ("yes" or "no")
 RT_LOOPBACK="yes"
 
+# Use the following RTnet protocol drivers
+RT_PROTOCOLS="udp packet"
+
 # Start capturing interface ("yes" or "no")
 RTCAP="no"
 
diff --git a/tools/rtnet.in b/tools/rtnet.in
index 251fada..5f797a6 100755
--- a/tools/rtnet.in
+++ b/tools/rtnet.in
@@ -33,9 +33,12 @@ EOF
 init_rtnet() {
     insmod $RTNET_MOD/rtnet$MODULE_EXT >/dev/null || exit 1
     insmod $RTNET_MOD/rtipv4$MODULE_EXT >/dev/null || exit 1
-    insmod $RTNET_MOD/rtpacket$MODULE_EXT >/dev/null || exit 1
     insmod $RTNET_MOD/$RT_DRIVER$MODULE_EXT $RT_DRIVER_OPTIONS >/dev/null || exit 1
 
+    for PROTOCOL in $RT_PROTOCOLS; do
+        insmod $RTNET_MOD/rt$PROTOCOL$MODULE_EXT >/dev/null || exit 1
+    done
+
     if [ $RT_LOOPBACK = "yes" ]; then
         insmod $RTNET_MOD/rt_loopback$MODULE_EXT >/dev/null || exit 1
     fi
@@ -307,7 +310,7 @@ case "$1" in
         $RTIFCONFIG rteth0 down 2>/dev/null
         $RTIFCONFIG rtlo down 2>/dev/null
 
-        rmmod tdma rtmac rtcfg rtcap rt_loopback $RT_DRIVER rtpacket rtipv4 rtnet 2>/dev/null
+        rmmod tdma rtmac rtcfg rtcap rt_loopback $RT_DRIVER rtpacket rtudp rttcp rtipv4 rtnet 2>/dev/null
         ;;
 
     master)
@@ -329,7 +332,10 @@ case "$1" in
     loopback)
         insmod $RTNET_MOD/rtnet$MODULE_EXT >/dev/null || exit 1
         insmod $RTNET_MOD/rtipv4$MODULE_EXT >/dev/null || exit 1
-        insmod $RTNET_MOD/rtpacket$MODULE_EXT >/dev/null || exit 1
+
+        for PROTOCOL in $RT_PROTOCOLS; do
+            insmod $RTNET_MOD/rt$PROTOCOL$MODULE_EXT >/dev/null || exit 1
+        done
 
         insmod $RTNET_MOD/rt_loopback$MODULE_EXT >/dev/null || exit 1
 
-- 
Sebastian

Re: [RTnet-developers] [PATCH] Add rtudp kernel module to RTnet loading/unloading script

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

Sebastian Smolorz wrote:
> With commit 525c907d8305fddbbfa54e68d9035608e08d2288 UDP support was split
> off into the separate kernel module rtudp, thus leaving rtipv4 kernel
> module without the former UDP support. This patch modifies the RTnet
> loading/unloading script to take care of this change so that RT-UDP is
> automatically loaded again.

Obviously, that's the scenario I did not properly test... (we are
running customized scripts theses days)

Given that we have now 3 protocol drivers to chose from, I think we
better handle them via some new rtnet.conf variable (e.g. RT_PROTOCOLS)
with "udp packet" as default. That way people will be able to easily add
"tcp" if required or drop disabled/unneeded modules.

Thanks,
Jan

> 
> Signed-off-by: Sebastian Smolorz <sm...@rt...>
> ---
>  tools/rtnet.in |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/rtnet.in b/tools/rtnet.in
> index 251fada..dddd852 100755
> --- a/tools/rtnet.in
> +++ b/tools/rtnet.in
> @@ -33,6 +33,7 @@ EOF
>  init_rtnet() {
>      insmod $RTNET_MOD/rtnet$MODULE_EXT >/dev/null || exit 1
>      insmod $RTNET_MOD/rtipv4$MODULE_EXT >/dev/null || exit 1
> +    insmod $RTNET_MOD/rtudp$MODULE_EXT >/dev/null || exit 1
>      insmod $RTNET_MOD/rtpacket$MODULE_EXT >/dev/null || exit 1
>      insmod $RTNET_MOD/$RT_DRIVER$MODULE_EXT $RT_DRIVER_OPTIONS >/dev/null || exit 1
>  
> @@ -307,7 +308,7 @@ case "$1" in
>          $RTIFCONFIG rteth0 down 2>/dev/null
>          $RTIFCONFIG rtlo down 2>/dev/null
>  
> -        rmmod tdma rtmac rtcfg rtcap rt_loopback $RT_DRIVER rtpacket rtipv4 rtnet 2>/dev/null
> +        rmmod tdma rtmac rtcfg rtcap rt_loopback $RT_DRIVER rtpacket rtudp rtipv4 rtnet 2>/dev/null
>          ;;
>  
>      master)
> @@ -329,6 +330,7 @@ case "$1" in
>      loopback)
>          insmod $RTNET_MOD/rtnet$MODULE_EXT >/dev/null || exit 1
>          insmod $RTNET_MOD/rtipv4$MODULE_EXT >/dev/null || exit 1
> +        insmod $RTNET_MOD/rtudp$MODULE_EXT >/dev/null || exit 1
>          insmod $RTNET_MOD/rtpacket$MODULE_EXT >/dev/null || exit 1
>  
>          insmod $RTNET_MOD/rt_loopback$MODULE_EXT >/dev/null || exit 1

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[RTnet-developers] [PATCH] Add rtudp kernel module to RTnet loading/unloading script

[Sebastian S. <sm...@rt...>]

With commit 525c907d8305fddbbfa54e68d9035608e08d2288 UDP support was split
off into the separate kernel module rtudp, thus leaving rtipv4 kernel
module without the former UDP support. This patch modifies the RTnet
loading/unloading script to take care of this change so that RT-UDP is
automatically loaded again.

Signed-off-by: Sebastian Smolorz <sm...@rt...>
---
 tools/rtnet.in |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/tools/rtnet.in b/tools/rtnet.in
index 251fada..dddd852 100755
--- a/tools/rtnet.in
+++ b/tools/rtnet.in
@@ -33,6 +33,7 @@ EOF
 init_rtnet() {
     insmod $RTNET_MOD/rtnet$MODULE_EXT >/dev/null || exit 1
     insmod $RTNET_MOD/rtipv4$MODULE_EXT >/dev/null || exit 1
+    insmod $RTNET_MOD/rtudp$MODULE_EXT >/dev/null || exit 1
     insmod $RTNET_MOD/rtpacket$MODULE_EXT >/dev/null || exit 1
     insmod $RTNET_MOD/$RT_DRIVER$MODULE_EXT $RT_DRIVER_OPTIONS >/dev/null || exit 1
 
@@ -307,7 +308,7 @@ case "$1" in
         $RTIFCONFIG rteth0 down 2>/dev/null
         $RTIFCONFIG rtlo down 2>/dev/null
 
-        rmmod tdma rtmac rtcfg rtcap rt_loopback $RT_DRIVER rtpacket rtipv4 rtnet 2>/dev/null
+        rmmod tdma rtmac rtcfg rtcap rt_loopback $RT_DRIVER rtpacket rtudp rtipv4 rtnet 2>/dev/null
         ;;
 
     master)
@@ -329,6 +330,7 @@ case "$1" in
     loopback)
         insmod $RTNET_MOD/rtnet$MODULE_EXT >/dev/null || exit 1
         insmod $RTNET_MOD/rtipv4$MODULE_EXT >/dev/null || exit 1
+        insmod $RTNET_MOD/rtudp$MODULE_EXT >/dev/null || exit 1
         insmod $RTNET_MOD/rtpacket$MODULE_EXT >/dev/null || exit 1
 
         insmod $RTNET_MOD/rt_loopback$MODULE_EXT >/dev/null || exit 1
-- 

[RTnet-developers] [ANNOUNCE] RTnet 0.9.12 released

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

Yet another year passed since the last release, so it's definitely time
to role out a new one. To make it short, the list of major changes:

- RT-TCP support
- support for Intel 82575 (igb)
- kernel support up to 2.6.32
- fixed IRQ conflict detection and enabled RT-IRQ sharing for most
  drivers
- fixed aligment issues in RTcfg and various management interfaces that
  specifically hit ARM platforms
- fixes that help packaging
- and more fixes all over the place
(find all details in the git log)

Many thanks again to all contributors to this version!

Hope I didn't mess up the release (I almost did) - guess I should do
this more often again. :)

Enjoy,
Jan

Re: [RTnet-developers] rtnet wireless configuration

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

Daniel Gregorek wrote:
> Hi Julian,
> 
> lets stay at the rtnet-developers list. I suspect this is a driver
> problem which has to be fixed. Can you uncomment the following line
> in rt2x00.h:
> 
> #define CONFIG_RT2X00_DEBUG
> 
> then recompile the driver, start over and post all the output you get 
> after typing the "dmesg" command.

Also, if the system crashes, it can be helpful to catch the oops message
it hopefully generates. Best done via a serial kernel console,
alternatively via netconsole.

Maybe there is an IRQ conflict between the rt2500 and some Linux driver.
Check the IRQ number it uses and compare it to /proc/interrupts. The
RTnet driver should detect and report spurious IRQs, but I'm not sure if
RTAI handles this properly.

Jan

> 
> Regards,
> Daniel
> 
>  Am Mon, 19 Apr 2010 11:01:03 +0000
> schrieb julian echeverry <ech...@ho...>:
> 
>> hello,
>> i need to make the communication wireless between a  master and slave
>> with the experimental hardware rt2500 . i do the configuration of the
>> ralink rt2500 card with this steps: 1. I remove the non-realtime
>> network card's device drivers and modules (rmmod 8139too, rt2500). 2.
>> I load the RTAI  modules (rtai_hal.ko, rtai_lxrt.ko, rtai_sem.ko,
>> rtai_rtdm.ko). 3. I load the RTNET  modules (rtnet.ko, rtipv4.ko,
>> rtpacket.ko). 4. I load the rt2500 card drivers realtime
>> (rt_rt2x00core.ko, rt_rt2500pci.ko, rt_loopback.ko). 5. I configure
>> the rtwlan0 interfaces with rtifconfig and rtiwconfig.
>>
>> I can do "./rtping <IP_ADDR_LOCAL>" to ping the local loopback
>> successfully, when i call "lsmod" , i find the realtime driver of the
>> network card in the loaded module list. But when i want check the
>> communication between the nodes an i run "./rtping <IP_ADDR_SLAVE>",
>> the computer crashes and i must restart the computer also when i want
>> to make the configuration of the routing table with "./rtroute
>> solicit <IP_ADDR_SLAVE> dev rtwlan0" the computer crashes. I do not
>> know what is the problem or i am wrong because with this steps the
>> communication in the wired network with RTNET working properly.
>>
>> Thanks for the help!!
>>
>>
>>    Julian Felipe Echeverry   Studente Laurea Specialistica Ingegneria
>> Meccatronica   Politecnico Di torino  Torino, Italia
>>
>>  		 	   		  

Re: [RTnet-developers] [PATCH] RTIPv4 Router: Fix configure and build

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

Sebastian Smolorz wrote:
> Hi Jan,
> 
> recently we discovered that RTnet's routing capability was broken. There is 
> a patch attached to correct the problem.
> 

Wow, that bug was really old, introduced with 1d870007 back in 2005!

Thanks, merged.

Jan

[RTnet-developers] [PATCH] RTIPv4 Router: Fix configure and build

[Sebastian S. <sm...@rt...>]

Hi Jan,

recently we discovered that RTnet's routing capability was broken. There is 
a patch attached to correct the problem.

Sebastian

Re: [RTnet-developers] rtnet wireless configuration

[Daniel G. <dx...@gm...>]

Hi Julian,

lets stay at the rtnet-developers list. I suspect this is a driver
problem which has to be fixed. Can you uncomment the following line
in rt2x00.h:

#define CONFIG_RT2X00_DEBUG

then recompile the driver, start over and post all the output you get 
after typing the "dmesg" command.

Regards,
Daniel

 Am Mon, 19 Apr 2010 11:01:03 +0000
schrieb julian echeverry <ech...@ho...>:

> 
> hello,
> i need to make the communication wireless between a  master and slave
> with the experimental hardware rt2500 . i do the configuration of the
> ralink rt2500 card with this steps: 1. I remove the non-realtime
> network card's device drivers and modules (rmmod 8139too, rt2500). 2.
> I load the RTAI  modules (rtai_hal.ko, rtai_lxrt.ko, rtai_sem.ko,
> rtai_rtdm.ko). 3. I load the RTNET  modules (rtnet.ko, rtipv4.ko,
> rtpacket.ko). 4. I load the rt2500 card drivers realtime
> (rt_rt2x00core.ko, rt_rt2500pci.ko, rt_loopback.ko). 5. I configure
> the rtwlan0 interfaces with rtifconfig and rtiwconfig.
> 
> I can do "./rtping <IP_ADDR_LOCAL>" to ping the local loopback
> successfully, when i call "lsmod" , i find the realtime driver of the
> network card in the loaded module list. But when i want check the
> communication between the nodes an i run "./rtping <IP_ADDR_SLAVE>",
> the computer crashes and i must restart the computer also when i want
> to make the configuration of the routing table with "./rtroute
> solicit <IP_ADDR_SLAVE> dev rtwlan0" the computer crashes. I do not
> know what is the problem or i am wrong because with this steps the
> communication in the wired network with RTNET working properly.
> 
> Thanks for the help!!
> 
> 
>    Julian Felipe Echeverry   Studente Laurea Specialistica Ingegneria
> Meccatronica   Politecnico Di torino  Torino, Italia
> 
>  		 	   		  
> _________________________________________________________________
> Hotmail: posta elettronica attendibile grazie alla protezione
> avanzata Microsoft dalla posta indesiderata.
> https://signup.live.com/signup.aspx?id=60969

[RTnet-developers] rtnet wireless configuration

[julian e. <ech...@ho...>]

hello,
i need to make the communication wireless between a  master and slave with the experimental hardware rt2500 .
i do the configuration of the ralink rt2500 card with this steps:
1. I remove the non-realtime network card's device drivers and modules (rmmod 8139too, rt2500).
2. I load the RTAI  modules (rtai_hal.ko, rtai_lxrt.ko, rtai_sem.ko, rtai_rtdm.ko).
3. I load the RTNET  modules (rtnet.ko, rtipv4.ko, rtpacket.ko).
4. I load the rt2500 card drivers realtime (rt_rt2x00core.ko, rt_rt2500pci.ko, rt_loopback.ko).
5. I configure the rtwlan0 interfaces with rtifconfig and rtiwconfig.

I can do "./rtping <IP_ADDR_LOCAL>" to ping the local loopback successfully, when i call "lsmod" , i find the realtime driver of the network card in the loaded module list.
But when i want check the communication between the nodes an i run "./rtping <IP_ADDR_SLAVE>", the computer crashes and i must restart the computer also when i want to make the configuration of the routing table with "./rtroute solicit <IP_ADDR_SLAVE> dev rtwlan0" the computer crashes.
I do not know what is the problem or i am wrong because with this steps the communication in the wired network with RTNET working properly.

Thanks for the help!!


   Julian Felipe Echeverry   Studente Laurea Specialistica Ingegneria Meccatronica   Politecnico Di torino  Torino, Italia

 		 	   		  
_________________________________________________________________
Hotmail: posta elettronica attendibile grazie alla protezione avanzata Microsoft dalla posta indesiderata.
https://signup.live.com/signup.aspx?id=60969

Re: [RTnet-developers] [BUG] rttcp.ko: __divdi3 undefined

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

Sebastian Smolorz wrote:
> Hello Jan,
> 
> when trying to compile RT-TCP we get the following warning:
> 
>   CC [M]  /home/smolorz/tmp/tmp/rtnet/stack/ipv4/tcp/tcp.o
>   CC [M]  /home/smolorz/tmp/tmp/rtnet/stack/ipv4/tcp/timerwheel.o
>   LD [M]  /home/smolorz/tmp/tmp/rtnet/stack/ipv4/tcp/rttcp.o
>   Building modules, stage 2.
>   MODPOST 1 modules
> WARNING: "__divdi3" [/home/smolorz/tmp/tmp/rtnet/stack/ipv4/tcp/rttcp.ko] 
> undefined!
> 
> The reason is line 160 in timerwheel.c (division of a 64 bit variable).
> 
> We compile for x86_32.

Trivial fix committed.

Jan

[RTnet-developers] [BUG] rttcp.ko: __divdi3 undefined

[Sebastian S. <sm...@rt...>]

Hello Jan,

when trying to compile RT-TCP we get the following warning:

  CC [M]  /home/smolorz/tmp/tmp/rtnet/stack/ipv4/tcp/tcp.o
  CC [M]  /home/smolorz/tmp/tmp/rtnet/stack/ipv4/tcp/timerwheel.o
  LD [M]  /home/smolorz/tmp/tmp/rtnet/stack/ipv4/tcp/rttcp.o
  Building modules, stage 2.
  MODPOST 1 modules
WARNING: "__divdi3" [/home/smolorz/tmp/tmp/rtnet/stack/ipv4/tcp/rttcp.ko] 
undefined!

The reason is line 160 in timerwheel.c (division of a 64 bit variable).

We compile for x86_32.

-- 
Sebastian

Re: [RTnet-developers] [RFT] RT-safe TCP support for RTnet

[Vladimir Z. <vla...@si...>]

Firstly I desire to appreciate inestimable support from Jan in this
development, and I believe that even basic TCP realization in part of
RTnet will find its niche in communication solutions.

Basically the development ought to be continued, because some naturally
expected features like silly window syndrome overcoming and full blown 
server side still aren't implemented.

Hope to know any feedback of TCP in RTNet audacious usage :)

Jan Kiszka wrote:
> "TCP/IP is not supported, because it is not real-time, and there is
> no clear way to force it to be real-time.  If you don't believe me, feel
> free to try implementing TCP/IP yourself.  If necessary, an unlimited
> quantity of you-can't-do-that hubris can be provided as encouragement."
> 
> [David Schleef, developer of the original RTnet, about 10 years ago,
> http://www.rtnet.org/download/original-rtnet-0.9.1.tgz]
> 
> We are not claiming to have proven him completely wrong, but - as always
> - nothing is pure black or white. :)
> 
> 
> We are happy to announce the availability of basic but functional TCP
> support for RTnet! Check out latest git, switch on
> CONFIG_RTNET_RTIPV4_TCP, and maybe run the included examples.
> 
> Just please do not expect that everything is as "shiny" as with
> full-blown TCP stacks. The primary use case are TCP clients under RT
> constraints, connecting to existing devices that only talk this
> language. We do support the server scenario nevertheless, but accept()
> behaves a bit differently and some corner cases may not yet work perfectly.
> 
> Moreover, you have to tune your socket for sufficient packet buffers,
> specifically as you need to keep a temporary copy of each transmitted
> fragment around for the sake of retransmission on error. This is, BTW,
> limited to 3 tries so that the application is able to handle the error
> before its too late. Check out Documentation/README.tcp for more details.
> 
> Lots of credits go to Vladimir who did the hard work of developing this
> complex beast from scratch. Thanks a lot!
> 
> And I know at least one person outside Siemens is already waiting to try
> this out - so don't hesitate, we hope to hear your feedback.
> 
> Jan
> 

Vladimir

[RTnet-developers] [RFT] RT-safe TCP support for RTnet

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

"TCP/IP is not supported, because it is not real-time, and there is
no clear way to force it to be real-time.  If you don't believe me, feel
free to try implementing TCP/IP yourself.  If necessary, an unlimited
quantity of you-can't-do-that hubris can be provided as encouragement."

[David Schleef, developer of the original RTnet, about 10 years ago,
http://www.rtnet.org/download/original-rtnet-0.9.1.tgz]

We are not claiming to have proven him completely wrong, but - as always
- nothing is pure black or white. :)


We are happy to announce the availability of basic but functional TCP
support for RTnet! Check out latest git, switch on
CONFIG_RTNET_RTIPV4_TCP, and maybe run the included examples.

Just please do not expect that everything is as "shiny" as with
full-blown TCP stacks. The primary use case are TCP clients under RT
constraints, connecting to existing devices that only talk this
language. We do support the server scenario nevertheless, but accept()
behaves a bit differently and some corner cases may not yet work perfectly.

Moreover, you have to tune your socket for sufficient packet buffers,
specifically as you need to keep a temporary copy of each transmitted
fragment around for the sake of retransmission on error. This is, BTW,
limited to 3 tries so that the application is able to handle the error
before its too late. Check out Documentation/README.tcp for more details.

Lots of credits go to Vladimir who did the hard work of developing this
complex beast from scratch. Thanks a lot!

And I know at least one person outside Siemens is already waiting to try
this out - so don't hesitate, we hope to hear your feedback.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [RTnet-developers] [PATCH] "Suspending kernel thread 'rtcfg-rx' after exception" on ns9xxx

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

Jan Kiszka wrote:
> James Kilts wrote:
>>> I'm fine with that script add-on, I would just call it "capturing mode"
>>> ("-c") as it does more that just enabling promisc in the RT-NICs.
>> Done.
>>
>>
>>> ...actually belongs here (because here we know that there is a 4-byte IP
>>> address at announce->addr).
>> Oops.  For performance (with multiple iterations of the loop) I
>> figured that doing it once would be better.  Although, if
>> announce->addr is not valid all of the time, then it's clearly not a
>> safe operation.  I've modified the code as you suggested.
>>
>>
>>> PS: Consider using git to ease your patch management.
>> This is being submitted from my home machine running Windows.  Three
>> patches ago, diff seemed like the obvious choice.  :-)
>>
> 
> The beginning is usually painful, and I can imagine using Windows as
> platform doesn't make this better :). But it pays off once you start
> juggling with a non-trivial amount of changes.
> 
> OK, the patches look good. I just need a short subject line per patch
> (short enough that it doesn't wrap).
> 

Fixed up manually and pushed the patches unchanged otherwise.

Thanks again,
Jan

Re: [RTnet-developers] removing rtipv4

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

Dietrich Pescoller wrote:
> Dear All,
> 
> after using rtnet whenever I try to remove the rtipv4 module
> I get
> ERROR: Removing 'rtipv4': Device or resource busy
> allthough from lsmod rtipv4 seems not to be used...
> 
> this is my lsmod  output
> 
> rt_loopback             2308  0
> rt_e1000               88512  0
> rtpacket                5216  0
> rtipv4                 25080  0
> rtnet                  30176  4 rt_loopback,rt_e1000,rtpacket,rtipv4
> rtai_rtdm              44228  4 rt_e1000,rtpacket,rtipv4,rtnet
> 
> I have to reboot in order to be able to remove the modules, which is not very 
> comfortable.
> I m using rtnet-0.9.11
> 
> Thanks in advance for any suggestion.

Are you trying a manual remove (rmmod / modprobe -r), or is this
messages generated while running the rtnet script? Does repeating 'rmmod
rtipv4' at the stage printed above give you that message?

Jan

[RTnet-developers] removing rtipv4

[Dietrich P. <dpe...@mi...>]

Dear All,

after using rtnet whenever I try to remove the rtipv4 module
I get
ERROR: Removing 'rtipv4': Device or resource busy
allthough from lsmod rtipv4 seems not to be used...

this is my lsmod  output

rt_loopback             2308  0
rt_e1000               88512  0
rtpacket                5216  0
rtipv4                 25080  0
rtnet                  30176  4 rt_loopback,rt_e1000,rtpacket,rtipv4
rtai_rtdm              44228  4 rt_e1000,rtpacket,rtipv4,rtnet

I have to reboot in order to be able to remove the modules, which is not very 
comfortable.
I m using rtnet-0.9.11

Thanks in advance for any suggestion.
-- 
MICROGATE S.r.l.
Via Stradivari, 4
I-39100 BOLZANO-BOZEN (ITALY)
P.I. 00709780217
Tel. 0471-501532
Fax. 0471-501524
Cell. +393357879496
http://www.microgate.it/engineering/

Re: [RTnet-developers] [PATCH] "Suspending kernel thread 'rtcfg-rx' after exception" on ns9xxx

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

James Kilts wrote:
>> I'm fine with that script add-on, I would just call it "capturing mode"
>> ("-c") as it does more that just enabling promisc in the RT-NICs.
> 
> Done.
> 
> 
>> ...actually belongs here (because here we know that there is a 4-byte IP
>> address at announce->addr).
> 
> Oops.  For performance (with multiple iterations of the loop) I
> figured that doing it once would be better.  Although, if
> announce->addr is not valid all of the time, then it's clearly not a
> safe operation.  I've modified the code as you suggested.
> 
> 
>> PS: Consider using git to ease your patch management.
> 
> This is being submitted from my home machine running Windows.  Three
> patches ago, diff seemed like the obvious choice.  :-)
> 

The beginning is usually painful, and I can imagine using Windows as
platform doesn't make this better :). But it pays off once you start
juggling with a non-trivial amount of changes.

OK, the patches look good. I just need a short subject line per patch
(short enough that it doesn't wrap).

TIA,
Jan

Re: [RTnet-developers] [PATCH] "Suspending kernel thread 'rtcfg-rx' after exception" on ns9xxx

[James K. <jam...@gm...>]

> I'm fine with that script add-on, I would just call it "capturing mode"
> ("-c") as it does more that just enabling promisc in the RT-NICs.

Done.


> ...actually belongs here (because here we know that there is a 4-byte IP
> address at announce->addr).

Oops.  For performance (with multiple iterations of the loop) I
figured that doing it once would be better.  Although, if
announce->addr is not valid all of the time, then it's clearly not a
safe operation.  I've modified the code as you suggested.


> PS: Consider using git to ease your patch management.

This is being submitted from my home machine running Windows.  Three
patches ago, diff seemed like the obvious choice.  :-)


- James

Re: [RTnet-developers] "Suspending kernel thread 'rtcfg-rx' after exception" on ns9xxx

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

James Kilts wrote:
> The patches are now broken into different parts and attached as files to
> avoid the line breaking.  While I was at it I added a patch that allows one
> to specify promiscuous mode from the command line while running as master or
> slave (this was quite valuable for me).

I'm fine with that script add-on, I would just call it "capturing mode"
("-c") as it does more that just enabling promisc in the RT-NICs.

Moreover:

> diff -U 3 -HbdprN -- rtnet-0.9.11_original/stack/rtcfg/rtcfg_event.c rtnet-0.9.11/stack/rtcfg/rtcfg_event.c
> --- rtnet-0.9.11_original/stack/rtcfg/rtcfg_event.c	2009-11-12 11:36:56.000000000 +0100
> +++ rtnet-0.9.11/stack/rtcfg/rtcfg_event.c	2009-12-11 16:45:07.000000000 +0100
> @@ -506,6 +507,7 @@ static int rtcfg_server_recv_announce(in
>      struct list_head          *entry;
>      struct rtcfg_frm_announce *announce;
>      struct rtcfg_connection   *conn;
> +    u32                        announce_addr;
>  
>  
>      if (rtskb->len < sizeof(struct rtcfg_frm_announce)) {
> @@ -516,6 +518,8 @@ static int rtcfg_server_recv_announce(in
>  
>      announce = (struct rtcfg_frm_announce *)rtskb->data;
>  
> +    memcpy(&announce_addr, announce->addr, 4);
> +

This line...

>      list_for_each(entry, &rtcfg_dev->spec.srv.conn_list) {
>          conn = list_entry(entry, struct rtcfg_connection, entry);
>  
> @@ -523,7 +527,7 @@ static int rtcfg_server_recv_announce(in
>  #ifdef CONFIG_RTNET_RTIPV4
>              case RTCFG_ADDR_IP:

...actually belongs here (because here we know that there is a 4-byte IP
address at announce->addr).

>                  if (((conn->addr_type & RTCFG_ADDR_MASK) == RTCFG_ADDR_IP) &&
> -                    (*(u32 *)announce->addr == conn->addr.ip_addr)) {
> +                    (announce_addr == conn->addr.ip_addr)) {
>                      /* save MAC address - Ethernet-specific! */
>                      memcpy(conn->mac_addr, rtskb->mac.ethernet->h_source,
>                             ETH_ALEN);

Final wish: Please find proper titles for all patches and (unless they
are trivial) a few lines as commit message. Then don't forget your
Signed-off-by, and I will happily merge them.

Thanks!
Jan

PS: Consider using git to ease your patch management.

Re: [RTnet-developers] "Suspending kernel thread 'rtcfg-rx' after exception" on ns9xxx

[James K. <jam...@gm...>]

The patches are now broken into different parts and attached as files to
avoid the line breaking.  While I was at it I added a patch that allows one
to specify promiscuous mode from the command line while running as master or
slave (this was quite valuable for me).

Thanks again,

- James



On Fri, Dec 11, 2009 at 10:59 AM, Jan Kiszka <jan...@si...> wrote:

> James Kilts wrote:
> > Here are a few patches that correct the memory alignment issues.  The
> first
> > file also contains a change from "break" to "return" because the variable
> > "stage_1_cfg" is used after the loop and is really just "rtskb->data"
> which
> > is freed using kfree_rtskb() before the break.  The change to
> rtmac_proto.c
> > was useful to me while tracking down an alignment issue, but if this last
> > change was "accidentally" lost it wouldn't matter.  :-)
> >
> > Syntactically I prefer dereferencing since it's easier to see what the
> code
> > does at a glance (perhaps someone has a preference toward get_unaligned()
> > and put_unaligned() instead).  But consistency with the rest of the code
> > seems to demand memcpy().
>
> All good catches, thanks! I just have a few style remarks below, and I
> would like to ask you to properly slit up the patches:
>  - unaligned access fixes
>  - break->return fix
>  - instrumentation enhancement
>
> Moreover, when reposting, make sure that those patches are not
> line-wrapped like this one.
>
> >
> > - James
> >
> >
> >
> > _____________________________
> >
> >
> >
> >
> > Signed-off-by: James Kilts <jameskilts <at> google's mail service>
>
> Your mail shows up in clear text when you go to public mailing lists, no
> need to obfuscate, and I also prefer readable addresses in the git log.
>
> > ---
> >
> >
> > diff -ru rtnet-0.9.11_original/stack/rtcfg/rtcfg_client_event.c
> > rtnet-0.9.11/stack/rtcfg/rtcfg_client_event.c
> > --- rtnet-0.9.11_original/stack/rtcfg/rtcfg_client_event.c    2009-11-12
> > 11:36:56.000000000 +0100
> > +++ rtnet-0.9.11/stack/rtcfg/rtcfg_client_event.c    2009-12-10
> > 16:07:16.000000000 +0100
> > @@ -598,24 +622,24 @@
> >              if (rtskb->len < sizeof(struct rtcfg_frm_stage_1_cfg) +
> >                      2*RTCFG_ADDRSIZE_IP) {
> >                  rtdm_mutex_unlock(&rtcfg_dev->dev_mutex);
> >                  RTCFG_DEBUG(1, "RTcfg: received invalid stage_1_cfg "
> >                              "frame\n");
> >                  kfree_rtskb(rtskb);
> > -                break;
> > +                return;
> >              }
> >
> >              rtdev = rtskb->rtdev;
> >
> > -            daddr = *(u32*)stage_1_cfg->client_addr;
> > +            memcpy(&daddr, stage_1_cfg->client_addr, 4);
> >              stage_1_cfg = (struct rtcfg_frm_stage_1_cfg *)
> >                  (((u8 *)stage_1_cfg) + RTCFG_ADDRSIZE_IP);
> >
> > -            saddr = *(u32*)stage_1_cfg->server_addr;
> > +            memcpy(&saddr, stage_1_cfg->server_addr, 4);
> >              stage_1_cfg = (struct rtcfg_frm_stage_1_cfg *)
> >                  (((u8 *)stage_1_cfg) + RTCFG_ADDRSIZE_IP);
> >
> >              __rtskb_pull(rtskb, 2*RTCFG_ADDRSIZE_IP);
> >
> >              /* Broadcast: IP is used to address client */
> >              if (rtskb->pkt_type == PACKET_BROADCAST) {
> >                  /* directed to us? */
> > @@ -748,6 +773,7 @@
> >      struct rtcfg_frm_announce *announce_frm;
> >      struct rtcfg_device       *rtcfg_dev = &device[ifindex];
> >      u32                       i;
> > +    u32                       announce_from_addr;
> >      int                       result;
> >
> >
> > @@ -771,8 +797,10 @@
> >                  return -EINVAL;
> >              }
> >
> > +            memcpy(&announce_from_addr, announce_frm->addr, 4);
> > +
> >              /* update routing table */
> > -            rt_ip_route_add_host(*(u32 *)announce_frm->addr,
> > +            rt_ip_route_add_host(announce_from_addr,
> >                                   rtskb->mac.ethernet->h_source,
> > rtskb->rtdev);
> >
> >              announce_frm = (struct rtcfg_frm_announce *)
> > @@ -1045,7 +1073,7 @@
> >                  return;
> >              }
> >
> > -            ip = *(u32 *)dead_station_frm->logical_addr;
> > +            memcpy(&ip, dead_station_frm->logical_addr, 4);
> >
> >              /* only delete remote IPs from routing table */
> >              if (rtskb->rtdev->local_ip != ip)
> > @@ -1132,11 +1160,11 @@
> >
> >              rtdev = rtskb->rtdev;
> >
> > -            daddr = *(u32*)stage_1_cfg->client_addr;
> > +            memcpy(&daddr, stage_1_cfg->client_addr, 4);
> >              stage_1_cfg = (struct rtcfg_frm_stage_1_cfg *)
> >                  (((u8 *)stage_1_cfg) + RTCFG_ADDRSIZE_IP);
> >
> > -            saddr = *(u32*)stage_1_cfg->server_addr;
> > +            memcpy(&saddr, stage_1_cfg->server_addr, 4);
> >              stage_1_cfg = (struct rtcfg_frm_stage_1_cfg *)
> >                  (((u8 *)stage_1_cfg) + RTCFG_ADDRSIZE_IP);
> >
> > diff -ru rtnet-0.9.11_original/stack/rtcfg/rtcfg_event.c
> > rtnet-0.9.11/stack/rtcfg/rtcfg_event.c
> > --- rtnet-0.9.11_original/stack/rtcfg/rtcfg_event.c    2009-11-12
> > 11:36:56.000000000 +0100
> > +++ rtnet-0.9.11/stack/rtcfg/rtcfg_event.c    2009-12-10
> 16:22:28.000000000
> > +0100
> > @@ -523,7 +532,7 @@
> >  #ifdef CONFIG_RTNET_RTIPV4
> >              case RTCFG_ADDR_IP:
> >                  if (((conn->addr_type & RTCFG_ADDR_MASK) ==
> RTCFG_ADDR_IP)
> > &&
> > -                    (*(u32 *)announce->addr == conn->addr.ip_addr)) {
> > +                    (memcmp(announce->addr, &(conn->addr.ip_addr), 4) ==
> > 0)) {
>
> Better go via a local variable here that should carry announce->addr for
> the comparison.
>
> >                      /* save MAC address - Ethernet-specific! */
> >                      memcpy(conn->mac_addr,
> rtskb->mac.ethernet->h_source,
> >                             ETH_ALEN);
> >
> > diff -ru rtnet-0.9.11_original/stack/rtcfg/rtcfg_frame.c
> > rtnet-0.9.11/stack/rtcfg/rtcfg_frame.c
> > --- rtnet-0.9.11_original/stack/rtcfg/rtcfg_frame.c    2009-11-12
> > 11:36:56.000000000 +0100
> > +++ rtnet-0.9.11/stack/rtcfg/rtcfg_frame.c    2009-12-10
> 16:13:04.000000000
> > +0100
> > @@ -170,12 +170,12 @@
> >      if (stage_1_frm->addr_type == RTCFG_ADDR_IP) {
> >          rtskb_put(rtskb, 2*RTCFG_ADDRSIZE_IP);
> >
> > -        *(u32*)stage_1_frm->client_addr = conn->addr.ip_addr;
> > +        memcpy(stage_1_frm->client_addr, &(conn->addr.ip_addr), 4);
> >
> >          stage_1_frm = (struct rtcfg_frm_stage_1_cfg *)
> >              (((u8 *)stage_1_frm) + RTCFG_ADDRSIZE_IP);
> >
> > -        *(u32*)stage_1_frm->server_addr = rtdev->local_ip;
> > +        memcpy(stage_1_frm->server_addr, &(rtdev->local_ip), 4);
> >
> >          stage_1_frm = (struct rtcfg_frm_stage_1_cfg *)
> >              (((u8 *)stage_1_frm) + RTCFG_ADDRSIZE_IP);
> > @@ -332,7 +332,7 @@
> >      if (announce_new->addr_type == RTCFG_ADDR_IP) {
> >          rtskb_put(rtskb, RTCFG_ADDRSIZE_IP);
> >
> > -        *(u32*)announce_new->addr = rtdev->local_ip;
> > +        memcpy(announce_new->addr, &(rtdev->local_ip), 4);
> >
> >          announce_new = (struct rtcfg_frm_announce *)
> >              (((u8 *)announce_new) + RTCFG_ADDRSIZE_IP);
> > @@ -388,7 +388,7 @@
> >      if (announce_rpl->addr_type == RTCFG_ADDR_IP) {
> >          rtskb_put(rtskb, RTCFG_ADDRSIZE_IP);
> >
> > -        *(u32*)announce_rpl->addr = rtdev->local_ip;
> > +        memcpy(announce_rpl->addr, &(rtdev->local_ip), 4);
> >
> >          announce_rpl = (struct rtcfg_frm_announce *)
> >              (((u8 *)announce_rpl) + RTCFG_ADDRSIZE_IP);
> > @@ -512,7 +512,7 @@
> >      if (dead_station_frm->addr_type == RTCFG_ADDR_IP) {
> >          rtskb_put(rtskb, RTCFG_ADDRSIZE_IP);
> >
> > -        *(u32*)dead_station_frm->logical_addr = conn->addr.ip_addr;
> > +        memcpy(dead_station_frm->logical_addr, &(conn->addr.ip_addr),
> 4);
> >
> >          dead_station_frm = (struct rtcfg_frm_dead_station *)
> >              (((u8 *)dead_station_frm) + RTCFG_ADDRSIZE_IP);
> >
> > diff -ru rtnet-0.9.11_original/stack/rtmac/rtmac_proto.c
> > rtnet-0.9.11/stack/rtmac/rtmac_proto.c
> > --- rtnet-0.9.11_original/stack/rtmac/rtmac_proto.c    2009-11-12
> > 11:36:56.000000000 +0100
> > +++ rtnet-0.9.11/stack/rtmac/rtmac_proto.c    2009-12-10
> 12:31:44.000000000
> > +0100
> > @@ -50,7 +50,8 @@
> >
> >      if (hdr->ver != RTMAC_VERSION) {
> >          rtdm_printk("RTmac: received unsupported RTmac protocol version
> on
> > "
> > -                    "device %s\n", skb->rtdev->name);
> > +                    "device %s.  Got 0x%02x but expected 0x%02x.\n",
> > +                    skb->rtdev->name, hdr->ver, RTMAC_VERSION);
> >          goto error;
> >      }
> >
> >
> >
>
> Thanks again,
> Jan
>
> --
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
>

Re: [RTnet-developers] Only slave mode works on new port to ns9xxx

[James K. <jam...@gm...>]

> What rest to you refer to? There is no further payload beyond that five
> TDMA fields.

When the 8139too driver is acting as master, it generally contains "slot 0
200;if conf".  I guess I just assumed that these were meaningful since
"slot" and numbers seem like reasonable things for a TDMA protocol.  :-)
The 8139 driver must just be transmitting garbage at the end of the message
then.

It appears that moving xmit_stamp earlier has corrected the problem.  After
removing some debug messages the master/slave connection goes through with
the device as master.  I'm still a little concerned that the timestamp has
to occur so early (could this cause problems with the TDMA?).  It also seems
strange that just a few rtdm_printk's can cause the entire thing to fail so
completely.  I suppose I've got a bit more investigation to do, but it seems
to be working good so far with debug messages turned off.

Thank you so much for your help!

- James



On Fri, Dec 11, 2009 at 3:15 PM, Jan Kiszka <jan...@si...> wrote:

> James Kilts wrote:
> > Well, after populating the xmit_stamp field before calling
> dma_map_single() from hard_start_xmit(), it seems that at least that part is
> transmitted.  The rest of the payload, however, is still non-existent.
>
> What rest to you refer to? There is no further payload beyond that five
> TDMA fields.
>
> >  It looks like the packet should be 60 bytes long, but the skb->len is
> only 42 in hard_start_xmit().  I've verified that 42 is indeed the actual
> length, because anything beyond that is garbage data.
>
> Who is responsible for padding with the ns9xxx, the driver or the
> hardware (though there should be no difference between Linux operation
> and RTnet)? What does the receiver see of the sync frames?
>
> >
> > The source code in its current state is attached, as well as the packet
> capture as it was failing before (without timestamps), and the most recent
> capture with timestamps but still without the remaining payload.  The parts
> of interest for the driver are hard_start_xmit around line 1100 and the
> transmit interrupt around line 720.
> >
> > Thanks,
> > - James
> >
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
>