rtnet-developers — development-related list

Re: [RTnet-developers] [PATCH] rt_via-rhine: Distinguish driver name from linux counterpart

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

On 2011-04-19 17:30, Sebastian Smolorz wrote:
> rt_via-rhine's PCI driver name was called via-rhine, equal to
> the linux driver's name. Mixing RT with non-RT ethernet interfaces
> by setting the cards module option and afterwards loading the
> via-rhine module failed for this reason.
> 
> Signed-off-by: Sebastian Smolorz <sm...@rt...>
> ---
>  drivers/rt_via-rhine.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/rt_via-rhine.c b/drivers/rt_via-rhine.c
> index 80294d2..067dab9 100644
> --- a/drivers/rt_via-rhine.c
> +++ b/drivers/rt_via-rhine.c
> @@ -2016,7 +2016,7 @@ static void __devexit via_rhine_remove_one (struct pci_dev *pdev)
>  
>  
>  static struct pci_driver via_rhine_driver = {
> -	.name		= "via-rhine",
> +	.name		= DRV_NAME,
>  	.id_table	= via_rhine_pci_tbl,
>  	.probe		= via_rhine_init_one,
>  	.remove		= __devexit_p(via_rhine_remove_one),

Thanks, applied.

Jan

[RTnet-developers] [PATCH] rt_via-rhine: Distinguish driver name from linux counterpart

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

rt_via-rhine's PCI driver name was called via-rhine, equal to
the linux driver's name. Mixing RT with non-RT ethernet interfaces
by setting the cards module option and afterwards loading the
via-rhine module failed for this reason.

Signed-off-by: Sebastian Smolorz <sm...@rt...>
---
 drivers/rt_via-rhine.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/rt_via-rhine.c b/drivers/rt_via-rhine.c
index 80294d2..067dab9 100644
--- a/drivers/rt_via-rhine.c
+++ b/drivers/rt_via-rhine.c
@@ -2016,7 +2016,7 @@ static void __devexit via_rhine_remove_one (struct pci_dev *pdev)
 
 
 static struct pci_driver via_rhine_driver = {
-	.name		= "via-rhine",
+	.name		= DRV_NAME,
 	.id_table	= via_rhine_pci_tbl,
 	.probe		= via_rhine_init_one,
 	.remove		= __devexit_p(via_rhine_remove_one),
-- 
1.7.2.2

Re: [RTnet-developers] [PATCH] Fix copying and setting of MAC addresses

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

On 2011-04-18 16:24, Sebastian Smolorz wrote:
> Since kernel 2.6.31 dev_addr in struct net_device is a pointer and
> not an array itself. Memcpying or memsetting the MAC address with
> a sizeof(dev_addr) as length argument does not work properly as
> now the length of the pointer is taken and not the size of the
> array.
> 
> This patch sets the memcpy and memset lengths in three files to
> MAX_ADDR_LEN. This define exists in the kernel since the old 2.4
> days and didn't change its meaning, so it can be considered as a
> safe length to use for these memcpy and memset operations.
> 
> Signed-off-by: Sebastian Smolorz <sm...@rt...>
> ---
>  addons/rtcap.c           |    2 +-
>  addons/rtnetproxy.c      |    2 +-
>  stack/rtmac/rtmac_vnic.c |    2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/addons/rtcap.c b/addons/rtcap.c
> index c4a2ccb..ca58391 100644
> --- a/addons/rtcap.c
> +++ b/addons/rtcap.c
> @@ -302,7 +302,7 @@ static int tap_dev_open(struct net_device *dev)
>  {
>      memcpy(dev->dev_addr,
>             (*(struct rtnet_device **)netdev_priv(dev))->dev_addr,
> -           sizeof(dev->dev_addr));
> +           MAX_ADDR_LEN);
>  
>      return 0;
>  }
> diff --git a/addons/rtnetproxy.c b/addons/rtnetproxy.c
> index 2358d09..36d662b 100644
> --- a/addons/rtnetproxy.c
> +++ b/addons/rtnetproxy.c
> @@ -464,7 +464,7 @@ static int __init rtnetproxy_init(struct net_device *dev)
>      ether_setup(dev);
>      dev->tx_queue_len = 0;
>  #ifdef CONFIG_RTNET_ADDON_PROXY_ARP
> -    memcpy(dev->dev_addr, rtnetproxy_rtdev->dev_addr, sizeof(dev->dev_addr));
> +    memcpy(dev->dev_addr, rtnetproxy_rtdev->dev_addr, MAX_ADDR_LEN);
>  #else
>      dev->flags |= IFF_NOARP;
>  #endif
> diff --git a/stack/rtmac/rtmac_vnic.c b/stack/rtmac/rtmac_vnic.c
> index 5358028..9e929c5 100644
> --- a/stack/rtmac/rtmac_vnic.c
> +++ b/stack/rtmac/rtmac_vnic.c
> @@ -131,7 +131,7 @@ static int rtmac_vnic_copy_mac(struct net_device *dev)
>  {
>      memcpy(dev->dev_addr,
>             (*(struct rtnet_device **)netdev_priv(dev))->dev_addr,
> -           sizeof(dev->dev_addr));
> +           MAX_ADDR_LEN);
>  
>      return 0;
>  }

Thanks, applied and now also pushed.

Jan

Re: [RTnet-developers] [PATCH] rtmac: Fix copying of MAC addresses to vnic interfaces

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

Jan Kiszka wrote:
> On 2011-04-18 13:30, Sebastian Smolorz wrote:
> > Since kernel 2.6.31 dev_addr in struct net_device is a pointer and
> > not an array itself. Copying of the MAC address from rtethX to vnicX
> > did not work since then.
> > 
> > This patch sets the memcpy length to MAX_ADDR_LEN. This define
> > exists in the kernel since the old 2.4 days and didn't change its
> > meaning, so it can be considered as a safe length to use for this
> > memcpy operation.
> > 
> > Signed-off-by: Sebastian Smolorz <sm...@rt...>
> > ---
> > 
> >  stack/rtmac/rtmac_vnic.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/stack/rtmac/rtmac_vnic.c b/stack/rtmac/rtmac_vnic.c
> > index 5358028..9e929c5 100644
> > --- a/stack/rtmac/rtmac_vnic.c
> > +++ b/stack/rtmac/rtmac_vnic.c
> > @@ -131,7 +131,7 @@ static int rtmac_vnic_copy_mac(struct net_device
> > *dev)
> > 
> >  {
> >  
> >      memcpy(dev->dev_addr,
> >      
> >             (*(struct rtnet_device **)netdev_priv(dev))->dev_addr,
> > 
> > -           sizeof(dev->dev_addr));
> > +           MAX_ADDR_LEN);
> > 
> >      return 0;
> >  
> >  }
> 
> Good catch. Looks like there could be more regressions (git grep
> "sizeof.*dev_addr"). Could you check/fix them as well?

New patch sent. Two additional locations were affected.

-- 
Sebastian

[RTnet-developers] [PATCH] Fix copying and setting of MAC addresses

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

Since kernel 2.6.31 dev_addr in struct net_device is a pointer and
not an array itself. Memcpying or memsetting the MAC address with
a sizeof(dev_addr) as length argument does not work properly as
now the length of the pointer is taken and not the size of the
array.

This patch sets the memcpy and memset lengths in three files to
MAX_ADDR_LEN. This define exists in the kernel since the old 2.4
days and didn't change its meaning, so it can be considered as a
safe length to use for these memcpy and memset operations.

Signed-off-by: Sebastian Smolorz <sm...@rt...>
---
 addons/rtcap.c           |    2 +-
 addons/rtnetproxy.c      |    2 +-
 stack/rtmac/rtmac_vnic.c |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/addons/rtcap.c b/addons/rtcap.c
index c4a2ccb..ca58391 100644
--- a/addons/rtcap.c
+++ b/addons/rtcap.c
@@ -302,7 +302,7 @@ static int tap_dev_open(struct net_device *dev)
 {
     memcpy(dev->dev_addr,
            (*(struct rtnet_device **)netdev_priv(dev))->dev_addr,
-           sizeof(dev->dev_addr));
+           MAX_ADDR_LEN);
 
     return 0;
 }
diff --git a/addons/rtnetproxy.c b/addons/rtnetproxy.c
index 2358d09..36d662b 100644
--- a/addons/rtnetproxy.c
+++ b/addons/rtnetproxy.c
@@ -464,7 +464,7 @@ static int __init rtnetproxy_init(struct net_device *dev)
     ether_setup(dev);
     dev->tx_queue_len = 0;
 #ifdef CONFIG_RTNET_ADDON_PROXY_ARP
-    memcpy(dev->dev_addr, rtnetproxy_rtdev->dev_addr, sizeof(dev->dev_addr));
+    memcpy(dev->dev_addr, rtnetproxy_rtdev->dev_addr, MAX_ADDR_LEN);
 #else
     dev->flags |= IFF_NOARP;
 #endif
diff --git a/stack/rtmac/rtmac_vnic.c b/stack/rtmac/rtmac_vnic.c
index 5358028..9e929c5 100644
--- a/stack/rtmac/rtmac_vnic.c
+++ b/stack/rtmac/rtmac_vnic.c
@@ -131,7 +131,7 @@ static int rtmac_vnic_copy_mac(struct net_device *dev)
 {
     memcpy(dev->dev_addr,
            (*(struct rtnet_device **)netdev_priv(dev))->dev_addr,
-           sizeof(dev->dev_addr));
+           MAX_ADDR_LEN);
 
     return 0;
 }
-- 
1.7.2.2

Re: [RTnet-developers] [PATCH] rtmac: Fix copying of MAC addresses to vnic interfaces

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

On 2011-04-18 13:30, Sebastian Smolorz wrote:
> Since kernel 2.6.31 dev_addr in struct net_device is a pointer and
> not an array itself. Copying of the MAC address from rtethX to vnicX
> did not work since then.
> 
> This patch sets the memcpy length to MAX_ADDR_LEN. This define
> exists in the kernel since the old 2.4 days and didn't change its
> meaning, so it can be considered as a safe length to use for this
> memcpy operation.
> 
> Signed-off-by: Sebastian Smolorz <sm...@rt...>
> ---
>  stack/rtmac/rtmac_vnic.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/stack/rtmac/rtmac_vnic.c b/stack/rtmac/rtmac_vnic.c
> index 5358028..9e929c5 100644
> --- a/stack/rtmac/rtmac_vnic.c
> +++ b/stack/rtmac/rtmac_vnic.c
> @@ -131,7 +131,7 @@ static int rtmac_vnic_copy_mac(struct net_device *dev)
>  {
>      memcpy(dev->dev_addr,
>             (*(struct rtnet_device **)netdev_priv(dev))->dev_addr,
> -           sizeof(dev->dev_addr));
> +           MAX_ADDR_LEN);
>  
>      return 0;
>  }

Good catch. Looks like there could be more regressions (git grep
"sizeof.*dev_addr"). Could you check/fix them as well?

TIA,
Jan

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

[RTnet-developers] [PATCH] rtmac: Fix copying of MAC addresses to vnic interfaces

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

Since kernel 2.6.31 dev_addr in struct net_device is a pointer and
not an array itself. Copying of the MAC address from rtethX to vnicX
did not work since then.

This patch sets the memcpy length to MAX_ADDR_LEN. This define
exists in the kernel since the old 2.4 days and didn't change its
meaning, so it can be considered as a safe length to use for this
memcpy operation.

Signed-off-by: Sebastian Smolorz <sm...@rt...>
---
 stack/rtmac/rtmac_vnic.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/stack/rtmac/rtmac_vnic.c b/stack/rtmac/rtmac_vnic.c
index 5358028..9e929c5 100644
--- a/stack/rtmac/rtmac_vnic.c
+++ b/stack/rtmac/rtmac_vnic.c
@@ -131,7 +131,7 @@ static int rtmac_vnic_copy_mac(struct net_device *dev)
 {
     memcpy(dev->dev_addr,
            (*(struct rtnet_device **)netdev_priv(dev))->dev_addr,
-           sizeof(dev->dev_addr));
+           MAX_ADDR_LEN);
 
     return 0;
 }
-- 
1.7.2.2

[RTnet-developers] Best supported Network Adapter

[Renato M. M. <ren...@gm...>]

Dear Rtnet mailing list,
I'm just started to use the rtnet. I intend to mount a small network. I did
read the rtnet   supported network adapter list. I would like to know
between all of them which  adapter is the best supported. I mean the most
used and reliable.

Thanks in advance.

Renato Machado Monaro

Re: [RTnet-developers] rtnet-3.9.12 .amd64 rtai-3.8.1 build fail

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

On 2011-03-10 17:17, bvl wrote:
> On Wednesday 02 March 2011 08:16:29 Jan Kiszka wrote:
> 
>>> herewith
>>>
>>> make[1]: Entering directory `/home/RT/rtnet-0.9.12/scripts/kconfig'
>>> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -DLOCALE  -
>>> DCURSES_LOC="<ncurses.h>" -I/home/RT/rtnet-0.9.12/scripts/kconfig -c
>>> /home/RT/rtnet-0.9.12/scripts/kconfig/lxdialog/checklist.c -o
>>> lxdialog/checklist.o
>>> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -DLOCALE  -
>>> DCURSES_LOC="<ncurses.h>" -I/home/RT/rtnet-0.9.12/scripts/kconfig -c
>>> /home/RT/rtnet-0.9.12/scripts/kconfig/lxdialog/menubox.c -o
>>> lxdialog/menubox.o gcc -Wall -Wstrict-prototypes -O2
>>> -fomit-frame-pointer  -DLOCALE  - DCURSES_LOC="<ncurses.h>"
>>> -I/home/RT/rtnet-0.9.12/scripts/kconfig -c
>>> /home/RT/rtnet-0.9.12/scripts/kconfig/lxdialog/textbox.c -o
>>> lxdialog/textbox.o gcc -Wall -Wstrict-prototypes -O2
>>> -fomit-frame-pointer  -DLOCALE  - DCURSES_LOC="<ncurses.h>"
>>> -I/home/RT/rtnet-0.9.12/scripts/kconfig -c
>>> /home/RT/rtnet-0.9.12/scripts/kconfig/lxdialog/yesno.c -o
>>> lxdialog/yesno.o gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer 
>>> -DLOCALE  - DCURSES_LOC="<ncurses.h>"
>>> -I/home/RT/rtnet-0.9.12/scripts/kconfig -c
>>> /home/RT/rtnet-0.9.12/scripts/kconfig/lxdialog/inputbox.c -o
>>> lxdialog/inputbox.o
>>> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -DLOCALE  -
>>> DCURSES_LOC="<ncurses.h>" -I/home/RT/rtnet-0.9.12/scripts/kconfig -c
>>> /home/RT/rtnet-0.9.12/scripts/kconfig/lxdialog/util.c -o lxdialog/util.o
>>> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -DLOCALE  -
>>> DCURSES_LOC="<ncurses.h>" -I/home/RT/rtnet-0.9.12/scripts/kconfig -c
>>> /home/RT/rtnet-0.9.12/scripts/kconfig/lxdialog/lxdialog.c -o
>>> lxdialog/lxdialog.o
>>> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -DLOCALE  -
>>> DCURSES_LOC="<ncurses.h>" -I/home/RT/rtnet-0.9.12/scripts/kconfig -c
>>> /home/RT/rtnet-0.9.12/scripts/kconfig/lxdialog/msgbox.c -o
>>> lxdialog/msgbox.o gcc -o lxdialog/lxdialog lxdialog/checklist.o
>>> lxdialog/menubox.o lxdialog/textbox.o lxdialog/yesno.o
>>> lxdialog/inputbox.o lxdialog/util.o lxdialog/lxdialog.o
>>> lxdialog/msgbox.o -lncurses
>>> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -
>>> I/home/RT/rtnet-0.9.12/scripts/kconfig -c
>>> /home/RT/rtnet-0.9.12/scripts/kconfig/mconf.c
>>> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -
>>> I/home/RT/rtnet-0.9.12/scripts/kconfig -fPIC -c zconf.tab.c
>>> lex.zconf.c:2969: warning: 'input' defined but not used
>>> gcc -shared -o libkconfig.so zconf.tab.o
>>> gcc -o mconf mconf.o libkconfig.so -Wl,-
>>> rpath,/home/RT/rtnet-0.9.12/scripts/kconfig
>>> [?1049h(B[?7h[?1h=#
>>> # using defaults found in ../../.rtnet_config
>>> #
>>> interrupted(11)
>>
>> Interrupted? What did you do? Are you using some non-standard terminal?
>>
>> Jan
>>
>>> make[1]: *** [menuconfig] Error 1
>>> make[1]: Leaving directory `/home/RT/rtnet-0.9.12/scripts/kconfig'
>>> make: *** [mconf] Error 2
>>>
>>> -----------
>>> and same result whether run as root or normal user
> 
> I have fixed the problem,    it was due  to optimised clflags.  Once I 
> disabled these  rtnet-3.9.12 compiles on the x86_64 (pure64-bit) setup I use.  

Interesting. What's your compiler version?

> 
> Incidently attempts to compile rtfirewire on the said machine ( with or 
> without  optimised cflags)   resulted in  the message 'unsupported platform' 
> on running the configure script.    Attempts to compile rtnet  with the switch 
> --enable-ftfirewire understandably fails  as all the headers are missing 
> presumably from the  prefix of  installed rtfirewire.  This begs the 
> question:-
> 
> Is there a way to compile   rtnet  with rtfiirewire support using the source-
> code of  rtfirewire?

rtfirewire bitrotted severely over the past years. I doubt you will
easily make it work over current versions without touching code and
build system.

Jan

[RTnet-developers] RTnet hangs system when brought up with 10M traffic (100%)

[Ma A. <ale...@gm...>]

          If I sends 5M broadcast traffic  to RTnet (ARM board),  the system
will  do a deadlock .

          Have who any patch for the bug ?


                                  Thanks
                                   Alex

Re: [RTnet-developers] rtnet-3.9.12 .amd64 rtai-3.8.1 build fail

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

On 2011-03-01 17:27, bvl wrote:
> On Tuesday 01 March 2011 05:35:14 Jan Kiszka wrote:
>> On 2011-03-01 02:29, luxInteg wrote:
>>> On Monday 28 February 2011 19:42:51 Jan Kiszka wrote:
>>>> On 2011-02-28 21:10, luxInteg wrote:
>>>>> Greetings,
>>>>>
>>>>>
>>>>>
>>>>> I attempt to compile rtnet-0.9.12 on a computer with these:-
>>>>>
>>>>> ---cpu amd64  2 cores
>>>>> ---linux 2.6.32.2, gcc-4.4.2, RTAI-3.9.12
>>>>>
>>>>>
>>>>> I ran  gconfig then make
>>>>
>>>> May not work, probably unused for too long. Does "make menuconfig"
>>>> behave better?
>>>
>>> thanks for the suggestion but sadly little progress.
>>>
>>> I did the following:
>>>
>>> a)  ran make  menuconfig  as non-priv user   saved the config    but on
>>> makefile generation this  was reported:-
>>>
>>> configure error : line 11560
>>> .: .retnet_config file not found
>>> ### RT-extended kernel not found
>>
>> Please post full and original console log from "make menuconfig" until
>> the error message.
>>
>> Jan
> 
> herewith 
> 
> make[1]: Entering directory `/home/RT/rtnet-0.9.12/scripts/kconfig'
> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -DLOCALE  -
> DCURSES_LOC="<ncurses.h>" -I/home/RT/rtnet-0.9.12/scripts/kconfig -c 
> /home/RT/rtnet-0.9.12/scripts/kconfig/lxdialog/checklist.c -o 
> lxdialog/checklist.o
> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -DLOCALE  -
> DCURSES_LOC="<ncurses.h>" -I/home/RT/rtnet-0.9.12/scripts/kconfig -c 
> /home/RT/rtnet-0.9.12/scripts/kconfig/lxdialog/menubox.c -o lxdialog/menubox.o
> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -DLOCALE  -
> DCURSES_LOC="<ncurses.h>" -I/home/RT/rtnet-0.9.12/scripts/kconfig -c 
> /home/RT/rtnet-0.9.12/scripts/kconfig/lxdialog/textbox.c -o lxdialog/textbox.o
> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -DLOCALE  -
> DCURSES_LOC="<ncurses.h>" -I/home/RT/rtnet-0.9.12/scripts/kconfig -c 
> /home/RT/rtnet-0.9.12/scripts/kconfig/lxdialog/yesno.c -o lxdialog/yesno.o
> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -DLOCALE  -
> DCURSES_LOC="<ncurses.h>" -I/home/RT/rtnet-0.9.12/scripts/kconfig -c 
> /home/RT/rtnet-0.9.12/scripts/kconfig/lxdialog/inputbox.c -o 
> lxdialog/inputbox.o
> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -DLOCALE  -
> DCURSES_LOC="<ncurses.h>" -I/home/RT/rtnet-0.9.12/scripts/kconfig -c 
> /home/RT/rtnet-0.9.12/scripts/kconfig/lxdialog/util.c -o lxdialog/util.o
> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -DLOCALE  -
> DCURSES_LOC="<ncurses.h>" -I/home/RT/rtnet-0.9.12/scripts/kconfig -c 
> /home/RT/rtnet-0.9.12/scripts/kconfig/lxdialog/lxdialog.c -o 
> lxdialog/lxdialog.o
> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -DLOCALE  -
> DCURSES_LOC="<ncurses.h>" -I/home/RT/rtnet-0.9.12/scripts/kconfig -c 
> /home/RT/rtnet-0.9.12/scripts/kconfig/lxdialog/msgbox.c -o lxdialog/msgbox.o
> gcc -o lxdialog/lxdialog lxdialog/checklist.o lxdialog/menubox.o 
> lxdialog/textbox.o lxdialog/yesno.o lxdialog/inputbox.o lxdialog/util.o 
> lxdialog/lxdialog.o lxdialog/msgbox.o -lncurses
> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -
> I/home/RT/rtnet-0.9.12/scripts/kconfig -c 
> /home/RT/rtnet-0.9.12/scripts/kconfig/mconf.c
> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -
> I/home/RT/rtnet-0.9.12/scripts/kconfig -fPIC -c zconf.tab.c
> lex.zconf.c:2969: warning: 'input' defined but not used
> gcc -shared -o libkconfig.so zconf.tab.o
> gcc -o mconf mconf.o libkconfig.so -Wl,-
> rpath,/home/RT/rtnet-0.9.12/scripts/kconfig
> [?1049h(B[?7h[?1h=#
> # using defaults found in ../../.rtnet_config
> #
> interrupted(11)

Interrupted? What did you do? Are you using some non-standard terminal?

Jan

> make[1]: *** [menuconfig] Error 1
> make[1]: Leaving directory `/home/RT/rtnet-0.9.12/scripts/kconfig'
> make: *** [mconf] Error 2
> 
> -----------
> and same result whether run as root or normal user

Re: [RTnet-developers] rtnet-3.9.12 .amd64 rtai-3.8.1 build fail

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

On 2011-03-01 02:29, luxInteg wrote:
> On Monday 28 February 2011 19:42:51 Jan Kiszka wrote:
>> On 2011-02-28 21:10, luxInteg wrote:
>>> Greetings,
>>>
>>>
>>>
>>> I attempt to compile rtnet-0.9.12 on a computer with these:-
>>>
>>> ---cpu amd64  2 cores
>>> ---linux 2.6.32.2, gcc-4.4.2, RTAI-3.9.12
>>>
>>>
>>> I ran  gconfig then make
>>
>> May not work, probably unused for too long. Does "make menuconfig"
>> behave better?
>>
> thanks for the suggestion but sadly little progress.
> 
> I did the following:
> 
> a)  ran make  menuconfig  as non-priv user   saved the config    but on 
> makefile generation this  was reported:-
> 
> configure error : line 11560
> .: .retnet_config file not found
> ### RT-extended kernel not found

Please post full and original console log from "make menuconfig" until
the error message.

Jan

Re: [RTnet-developers] rtnet-3.9.12 .amd64 rtai-3.8.1 build fail

[luxInteg <lux...@bt...>]

On Monday 28 February 2011 19:42:51 Jan Kiszka wrote:
> On 2011-02-28 21:10, luxInteg wrote:
> > Greetings,
> > 
> > 
> > 
> > I attempt to compile rtnet-0.9.12 on a computer with these:-
> > 
> > ---cpu amd64  2 cores
> > ---linux 2.6.32.2, gcc-4.4.2, RTAI-3.9.12
> > 
> > 
> > I ran  gconfig then make
> 
> May not work, probably unused for too long. Does "make menuconfig"
> behave better?
> 
thanks for the suggestion but sadly little progress.

I did the following:

a)  ran make  menuconfig  as non-priv user   saved the config    but on 
makefile generation this  was reported:-

configure error : line 11560
.: .retnet_config file not found
### RT-extended kernel not found


b) My RTAI patched kernel did not have a symbolic link to /usr/src/linux and I 
was not working as root so I fixed  both of   these did a  'make clean'   and 
ran 'make menuconfig'  again.  The   result was as before.

Re: [RTnet-developers] rtnet-3.9.12 .amd64 rtai-3.8.1 build fail

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

On 2011-02-28 21:10, luxInteg wrote:
> Greetings,
> 
> 
> 
> I attempt to compile rtnet-0.9.12 on a computer with these:-
> 
> ---cpu amd64  2 cores
> ---linux 2.6.32.2, gcc-4.4.2, RTAI-3.9.12
> 
> 
> I ran  gconfig then make 

May not work, probably unused for too long. Does "make menuconfig"
behave better?

Jan

[RTnet-developers] rtnet-3.9.12 .amd64 rtai-3.8.1 build fail

[luxInteg <lux...@bt...>]

Greetings,



I attempt to compile rtnet-0.9.12 on a computer with these:-

---cpu amd64  2 cores
---linux 2.6.32.2, gcc-4.4.2, RTAI-3.9.12


I ran  gconfig then make 
make ends as follows:-

###############

make[1]: Entering directory `~/rtnet-0.9.12/scripts/kconfig'
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -DLOCALE  -
DCURSES_LOC="<ncurses.h>" -I~/rtnet-0.9.12/scripts/kconfig -c 
~/rtnet-0.9.12/scripts/kconfig/lxdialog/checklist.c -o lxdialog/checklist.o
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -DLOCALE  -
DCURSES_LOC="<ncurses.h>" -I~/rtnet-0.9.12/scripts/kconfig -c 
~/rtnet-0.9.12/scripts/kconfig/lxdialog/menubox.c -o lxdialog/menubox.o
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -DLOCALE  -
DCURSES_LOC="<ncurses.h>" -I~/rtnet-0.9.12/scripts/kconfig -c 
~/rtnet-0.9.12/scripts/kconfig/lxdialog/textbox.c -o lxdialog/textbox.o
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -DLOCALE  -
DCURSES_LOC="<ncurses.h>" -I~/rtnet-0.9.12/scripts/kconfig -c 
~/rtnet-0.9.12/scripts/kconfig/lxdialog/yesno.c -o lxdialog/yesno.o
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -DLOCALE  -
DCURSES_LOC="<ncurses.h>" -I~/rtnet-0.9.12/scripts/kconfig -c 
~/rtnet-0.9.12/scripts/kconfig/lxdialog/inputbox.c -o lxdialog/inputbox.o
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -DLOCALE  -
DCURSES_LOC="<ncurses.h>" -I~/rtnet-0.9.12/scripts/kconfig -c 
~/rtnet-0.9.12/scripts/kconfig/lxdialog/util.c -o lxdialog/util.o
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -DLOCALE  -
DCURSES_LOC="<ncurses.h>" -I~/rtnet-0.9.12/scripts/kconfig -c 
~/rtnet-0.9.12/scripts/kconfig/lxdialog/lxdialog.c -o lxdialog/lxdialog.o
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -DLOCALE  -
DCURSES_LOC="<ncurses.h>" -I~/rtnet-0.9.12/scripts/kconfig -c 
~/rtnet-0.9.12/scripts/kconfig/lxdialog/msgbox.c -o lxdialog/msgbox.o
gcc -o lxdialog/lxdialog lxdialog/checklist.o lxdialog/menubox.o 
lxdialog/textbox.o lxdialog/yesno.o lxdialog/inputbox.o lxdialog/util.o 
lxdialog/lxdialog.o lxdialog/msgbox.o -lncurses
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -
I~/rtnet-0.9.12/scripts/kconfig -c ~/rtnet-0.9.12/scripts/kconfig/mconf.c
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -
I~/rtnet-0.9.12/scripts/kconfig -fPIC -c zconf.tab.c
lex.zconf.c:2969: warning: 'input' defined but not used
gcc -shared -o libkconfig.so zconf.tab.o
gcc -o mconf mconf.o libkconfig.so -Wl,-rpath,~/rtnet-0.9.12/scripts/kconfig
[?1049h(B[?7h[?1h=#
# using defaults found in defconfig
#
interrupted(11)
make[1]: *** [menuconfig] Error 1
#########

advice/help would be appreciated

sincerely

lux-integ

Re: [RTnet-developers] [PATCH] Build fixes for 2.6.37

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

On 2011-02-17 13:46, Sebastian Smolorz wrote:
> VLAN_GROUP_ARRAY_LEN was renamed to VLAN_N_VID in kernel 2.6.37. Replace all
> occurrences of VLAN_GROUP_ARRAY_LEN in all drivers and define VLAN_N_VID for
> kernels prior to 2.6.37.
> 
> Signed-off-by: Sebastian Smolorz <sm...@rt...>
> ---
>  drivers/experimental/e1000/e1000_ethtool.c |    2 +-
>  drivers/experimental/e1000/e1000_main.c    |    2 +-
>  drivers/igb/igb_main.c                     |    2 +-
>  stack/include/rtnet_port.h                 |    4 ++++
>  4 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/experimental/e1000/e1000_ethtool.c b/drivers/experimental/e1000/e1000_ethtool.c
> index b891f4e..375aa7f 100644
> --- a/drivers/experimental/e1000/e1000_ethtool.c
> +++ b/drivers/experimental/e1000/e1000_ethtool.c
> @@ -378,7 +378,7 @@ static int e1000_set_tso(struct net_device *netdev, u32 data)
>  		/* disable TSO on all VLANs if they're present */
>  		if (!adapter->vlgrp)
>  			goto tso_out;
> -		for (i = 0; i < VLAN_GROUP_ARRAY_LEN; i++) {
> +		for (i = 0; i < VLAN_N_VID; i++) {
>  			v_netdev = vlan_group_get_device(adapter->vlgrp, i);
>  			if (!v_netdev)
>  				continue;
> diff --git a/drivers/experimental/e1000/e1000_main.c b/drivers/experimental/e1000/e1000_main.c
> index 1bd2a72..ce7f23a 100644
> --- a/drivers/experimental/e1000/e1000_main.c
> +++ b/drivers/experimental/e1000/e1000_main.c
> @@ -6147,7 +6147,7 @@ static void e1000_restore_vlan(struct e1000_adapter *adapter)
>  
>  	if (adapter->vlgrp) {
>  		u16 vid;
> -		for (vid = 0; vid < VLAN_GROUP_ARRAY_LEN; vid++) {
> +		for (vid = 0; vid < VLAN_N_VID; vid++) {
>  			if (!vlan_group_get_device(adapter->vlgrp, vid))
>  				continue;
>  			e1000_vlan_rx_add_vid(adapter->netdev, vid);
> diff --git a/drivers/igb/igb_main.c b/drivers/igb/igb_main.c
> index f9caeee..6272539 100644
> --- a/drivers/igb/igb_main.c
> +++ b/drivers/igb/igb_main.c
> @@ -4515,7 +4515,7 @@ static void igb_restore_vlan(struct igb_adapter *adapter)
>  
>  	if (adapter->vlgrp) {
>  		u16 vid;
> -		for (vid = 0; vid < VLAN_GROUP_ARRAY_LEN; vid++) {
> +		for (vid = 0; vid < VLAN_N_VID; vid++) {
>  			if (!vlan_group_get_device(adapter->vlgrp, vid))
>  				continue;
>  			igb_vlan_rx_add_vid(adapter->netdev, vid);
> diff --git a/stack/include/rtnet_port.h b/stack/include/rtnet_port.h
> index 09101cc..89b8a2b 100644
> --- a/stack/include/rtnet_port.h
> +++ b/stack/include/rtnet_port.h
> @@ -222,6 +222,10 @@ static inline void *netdev_priv(struct net_device *dev)
>  #define NIPQUAD_FMT "%u.%u.%u.%u"
>  #endif
>  
> +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37)
> +#define VLAN_N_VID VLAN_GROUP_ARRAY_LEN
> +#endif
> +
>  #endif /* __KERNEL__ */
>  
>  #endif /* __RTNET_PORT_H_ */

Thanks, applied.

Jan

[RTnet-developers] [PATCH] Build fixes for 2.6.37

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

VLAN_GROUP_ARRAY_LEN was renamed to VLAN_N_VID in kernel 2.6.37. Replace all
occurrences of VLAN_GROUP_ARRAY_LEN in all drivers and define VLAN_N_VID for
kernels prior to 2.6.37.

Signed-off-by: Sebastian Smolorz <sm...@rt...>
---
 drivers/experimental/e1000/e1000_ethtool.c |    2 +-
 drivers/experimental/e1000/e1000_main.c    |    2 +-
 drivers/igb/igb_main.c                     |    2 +-
 stack/include/rtnet_port.h                 |    4 ++++
 4 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/experimental/e1000/e1000_ethtool.c b/drivers/experimental/e1000/e1000_ethtool.c
index b891f4e..375aa7f 100644
--- a/drivers/experimental/e1000/e1000_ethtool.c
+++ b/drivers/experimental/e1000/e1000_ethtool.c
@@ -378,7 +378,7 @@ static int e1000_set_tso(struct net_device *netdev, u32 data)
 		/* disable TSO on all VLANs if they're present */
 		if (!adapter->vlgrp)
 			goto tso_out;
-		for (i = 0; i < VLAN_GROUP_ARRAY_LEN; i++) {
+		for (i = 0; i < VLAN_N_VID; i++) {
 			v_netdev = vlan_group_get_device(adapter->vlgrp, i);
 			if (!v_netdev)
 				continue;
diff --git a/drivers/experimental/e1000/e1000_main.c b/drivers/experimental/e1000/e1000_main.c
index 1bd2a72..ce7f23a 100644
--- a/drivers/experimental/e1000/e1000_main.c
+++ b/drivers/experimental/e1000/e1000_main.c
@@ -6147,7 +6147,7 @@ static void e1000_restore_vlan(struct e1000_adapter *adapter)
 
 	if (adapter->vlgrp) {
 		u16 vid;
-		for (vid = 0; vid < VLAN_GROUP_ARRAY_LEN; vid++) {
+		for (vid = 0; vid < VLAN_N_VID; vid++) {
 			if (!vlan_group_get_device(adapter->vlgrp, vid))
 				continue;
 			e1000_vlan_rx_add_vid(adapter->netdev, vid);
diff --git a/drivers/igb/igb_main.c b/drivers/igb/igb_main.c
index f9caeee..6272539 100644
--- a/drivers/igb/igb_main.c
+++ b/drivers/igb/igb_main.c
@@ -4515,7 +4515,7 @@ static void igb_restore_vlan(struct igb_adapter *adapter)
 
 	if (adapter->vlgrp) {
 		u16 vid;
-		for (vid = 0; vid < VLAN_GROUP_ARRAY_LEN; vid++) {
+		for (vid = 0; vid < VLAN_N_VID; vid++) {
 			if (!vlan_group_get_device(adapter->vlgrp, vid))
 				continue;
 			igb_vlan_rx_add_vid(adapter->netdev, vid);
diff --git a/stack/include/rtnet_port.h b/stack/include/rtnet_port.h
index 09101cc..89b8a2b 100644
--- a/stack/include/rtnet_port.h
+++ b/stack/include/rtnet_port.h
@@ -222,6 +222,10 @@ static inline void *netdev_priv(struct net_device *dev)
 #define NIPQUAD_FMT "%u.%u.%u.%u"
 #endif
 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37)
+#define VLAN_N_VID VLAN_GROUP_ARRAY_LEN
+#endif
+
 #endif /* __KERNEL__ */
 
 #endif /* __RTNET_PORT_H_ */
-- 
1.5.2.4

Re: [RTnet-developers] [PATCH] tcp: Build fix for 2.6.36

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

On 2011-02-16 17:57, Sebastian Smolorz wrote:
> Signed-off-by: Sebastian Smolorz <sm...@rt...>
> ---
>  stack/ipv4/tcp/tcp.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/stack/ipv4/tcp/tcp.c b/stack/ipv4/tcp/tcp.c
> index 7787ab7..5c831dc 100644
> --- a/stack/ipv4/tcp/tcp.c
> +++ b/stack/ipv4/tcp/tcp.c
> @@ -30,6 +30,7 @@
>  #include <rtnet_rtpc.h>
>  #include <rtskb.h>
>  #include <rtdev.h>
> +#include <rtnet_port.h>
>  #include <ipv4/tcp.h>
>  #include <ipv4/ip_sock.h>
>  #include <ipv4/ip_output.h>

Thanks, applied.

Jan

[RTnet-developers] [PATCH] tcp: Build fix for 2.6.36

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

Signed-off-by: Sebastian Smolorz <sm...@rt...>
---
 stack/ipv4/tcp/tcp.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/stack/ipv4/tcp/tcp.c b/stack/ipv4/tcp/tcp.c
index 7787ab7..5c831dc 100644
--- a/stack/ipv4/tcp/tcp.c
+++ b/stack/ipv4/tcp/tcp.c
@@ -30,6 +30,7 @@
 #include <rtnet_rtpc.h>
 #include <rtskb.h>
 #include <rtdev.h>
+#include <rtnet_port.h>
 #include <ipv4/tcp.h>
 #include <ipv4/ip_sock.h>
 #include <ipv4/ip_output.h>
-- 
1.5.2.4

Re: [RTnet-developers] Ethernet IP

[Glen W. <gl...@je...>]

Hi All,

Very strange question but how could I get a 1588 time stamp data from RTNet
for a UDP packet.

Glen


On 2/9/11 11:59 AM, "Jan Kiszka" <jan...@si...> wrote:

> On 2011-02-09 17:53, Glen Wernersbach wrote:
>> I have 10.82.88.249 with my Mac address in my rtroute table.
> 
> You mean with the right MAC of that remote host, no?
> 
>> I can receive from it but can't send back to the same socket.
>> 
>> I think this may be the connect() issue.
> 
> Does rtping 10.82.88.249 work?
> 
>> 
>> I will be getting a kernel dump when I get back to rtai but I would like to
>> get xenomai working if possible.
>> 
> 
> OK.
> 
> Jan

-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
----
"Support Dyslexia Research"

Re: [RTnet-developers] Ethernet IP

[Glen W. <gl...@je...>]

Jan,

First of thank you for your support.

I was able to ping myself by routing my NIC's ip address to RTETLO instead
of RTEH0

I was then able to get sendto() (not send) to work by addressing it to
INADDR_ANY after the recv().

This seemed to work but have a lot more testing to do.


On 2/9/11 11:59 AM, "Jan Kiszka" <jan...@si...> wrote:

> On 2011-02-09 17:53, Glen Wernersbach wrote:
>> I have 10.82.88.249 with my Mac address in my rtroute table.
> 
> You mean with the right MAC of that remote host, no?
> 
>> I can receive from it but can't send back to the same socket.
>> 
>> I think this may be the connect() issue.
> 
> Does rtping 10.82.88.249 work?
> 
>> 
>> I will be getting a kernel dump when I get back to rtai but I would like to
>> get xenomai working if possible.
>> 
> 
> OK.
> 
> Jan

-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
----
"Support Dyslexia Research"

Re: [RTnet-developers] Ethernet IP

[Glen W. <gl...@je...>]

Jan,

First of thank you for your support.

I was able to ping myself by routing my NIC's ip address to RTETLO instead
of RTEH0

I was then able to get sendto() (not send) to work by addressing it to
INADDR_ANY after the recv().

This seemed to work but have a lot more testing to do.


On 2/9/11 11:59 AM, "Jan Kiszka" <jan...@si...> wrote:

> On 2011-02-09 17:53, Glen Wernersbach wrote:
>> I have 10.82.88.249 with my Mac address in my rtroute table.
> 
> You mean with the right MAC of that remote host, no?
> 
>> I can receive from it but can't send back to the same socket.
>> 
>> I think this may be the connect() issue.
> 
> Does rtping 10.82.88.249 work?
> 
>> 
>> I will be getting a kernel dump when I get back to rtai but I would like to
>> get xenomai working if possible.
>> 
> 
> OK.
> 
> Jan

-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
----
"Support Dyslexia Research"

Re: [RTnet-developers] Ethernet IP

[Glen W. <gl...@je...>]

No I can't ping myself. Any ideas?

--
Glen Wernersbach
President & CTO
Jetsoft Development Co
629 Old St. Rt. 74 - Suite 210
Cincinnati Ohio 45244
Custom Programming Web Site: www.JetsoftDev.com
Retail Product Web Site: www.ScanHelp.com
Phone: 513-528-6660
Fax: 513-528-3470

On Feb 9, 2011, at 11:59 AM, Jan Kiszka <jan...@si...> wrote:

> On 2011-02-09 17:53, Glen Wernersbach wrote:
>> I have 10.82.88.249 with my Mac address in my rtroute table.
> 
> You mean with the right MAC of that remote host, no?
> 
>> I can receive from it but can't send back to the same socket.
>> 
>> I think this may be the connect() issue.
> 
> Does rtping 10.82.88.249 work?
> 
>> 
>> I will be getting a kernel dump when I get back to rtai but I would like to get xenomai working if possible.
>> 
> 
> OK.
> 
> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
> 

Re: [RTnet-developers] Ethernet IP

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

On 2011-02-09 17:53, Glen Wernersbach wrote:
> I have 10.82.88.249 with my Mac address in my rtroute table.

You mean with the right MAC of that remote host, no?

> I can receive from it but can't send back to the same socket.
> 
> I think this may be the connect() issue.

Does rtping 10.82.88.249 work?

> 
> I will be getting a kernel dump when I get back to rtai but I would like to get xenomai working if possible.
> 

OK.

Jan

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

Re: [RTnet-developers] Ethernet IP

[Glen W. <gl...@je...>]

I have 10.82.88.249 with my Mac address in my rtroute table. I can receive from it but can't send back to the same socket.

I think this may be the connect() issue.

I will be getting a kernel dump when I get back to rtai but I would like to get xenomai working if possible.


--
Glen Wernersbach
President & CTO
Jetsoft Development Co
629 Old St. Rt. 74 - Suite 210
Cincinnati Ohio 45244
Custom Programming Web Site: www.JetsoftDev.com
Retail Product Web Site: www.ScanHelp.com
Phone: 513-528-6660
Fax: 513-528-3470

On Feb 9, 2011, at 11:35 AM, Jan Kiszka <jan...@si...> wrote:

> On 2011-02-09 17:31, Glen Wernersbach wrote:
>> Jan, I did a kernel message while my send command was blocking 
>> 
>> It said 
>> RTNET host 10.82.88.249 unreachable.
>> 
>> 10.82.88.249 is the NIC I received the packette on.
> 
> That, first of all, means you are lacking a host route from your RTnet
> node to that target. Check with rtroute, see README.routing for more info.
> 
> But I was referring to that oops you mentioned under RTAI. It may point
> to an issue in the stack.
> 
> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
>