rtnet-developers Mailing List for RTnet - Real-Time Networking for Linux (Page 6)
Brought to you by:
bet-frogger,
kiszka
Menu
▾
▴
rtnet-developers — development-related list
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(9) |
Nov
(12) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(13) |
Feb
(1) |
Mar
(2) |
Apr
|
May
(7) |
Jun
(13) |
Jul
(6) |
Aug
(15) |
Sep
(1) |
Oct
(3) |
Nov
(2) |
Dec
(11) |
| 2006 |
Jan
(2) |
Feb
|
Mar
(13) |
Apr
|
May
(6) |
Jun
(7) |
Jul
(8) |
Aug
(13) |
Sep
(28) |
Oct
(5) |
Nov
(17) |
Dec
(5) |
| 2007 |
Jan
(2) |
Feb
(18) |
Mar
(22) |
Apr
(5) |
May
(4) |
Jun
(2) |
Jul
(5) |
Aug
(22) |
Sep
|
Oct
(3) |
Nov
(4) |
Dec
(2) |
| 2008 |
Jan
|
Feb
(3) |
Mar
(15) |
Apr
(7) |
May
(2) |
Jun
(18) |
Jul
(19) |
Aug
(6) |
Sep
(7) |
Oct
(2) |
Nov
(3) |
Dec
(1) |
| 2009 |
Jan
(8) |
Feb
(2) |
Mar
|
Apr
(3) |
May
(4) |
Jun
(2) |
Jul
(7) |
Aug
|
Sep
(2) |
Oct
(8) |
Nov
(16) |
Dec
(16) |
| 2010 |
Jan
(5) |
Feb
(2) |
Mar
|
Apr
(16) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(8) |
Oct
(20) |
Nov
|
Dec
(10) |
| 2011 |
Jan
(15) |
Feb
(33) |
Mar
(5) |
Apr
(8) |
May
(5) |
Jun
|
Jul
|
Aug
(2) |
Sep
(21) |
Oct
(21) |
Nov
(12) |
Dec
(7) |
| 2012 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(5) |
Oct
|
Nov
|
Dec
(2) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
| 2014 |
Jan
|
Feb
(3) |
Mar
(5) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(2) |
Nov
(8) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jan K. <jan...@we...> - 2011-04-20 08:06:40
|
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
|
|
From: Sebastian S. <sm...@rt...> - 2011-04-19 15:30:17
|
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
|
|
From: Jan K. <jan...@we...> - 2011-04-18 19:31:12
|
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
|
|
From: Sebastian S. <sm...@rt...> - 2011-04-18 14:26:51
|
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
|
|
From: Sebastian S. <sm...@rt...> - 2011-04-18 14:24:22
|
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
|
|
From: Jan K. <jan...@si...> - 2011-04-18 12:35:47
|
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
|
|
From: Sebastian S. <sm...@rt...> - 2011-04-18 11:52:27
|
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
|
|
From: Renato M. M. <ren...@gm...> - 2011-04-07 20:54:06
|
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 |
|
From: Jan K. <jan...@we...> - 2011-03-11 00:23:27
|
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[1;24r(B[m[4l[?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 |
|
From: Ma A. <ale...@gm...> - 2011-03-08 06:05:25
|
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
|
|
From: Jan K. <jan...@we...> - 2011-03-02 08:16:40
|
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[1;24r(B[m[4l[?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 |
|
From: Jan K. <jan...@we...> - 2011-03-01 05:35:32
|
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 |
|
From: luxInteg <lux...@bt...> - 2011-03-01 00:25:30
|
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. |
|
From: Jan K. <jan...@we...> - 2011-02-28 19:42:58
|
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 |
|
From: luxInteg <lux...@bt...> - 2011-02-28 19:06:24
|
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[1;24r(B[m[4l[?7h[?1h=# # using defaults found in defconfig # interrupted(11) make[1]: *** [menuconfig] Error 1 ######### advice/help would be appreciated sincerely lux-integ |
|
From: Jan K. <jan...@we...> - 2011-02-17 22:50:18
|
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
|
|
From: Sebastian S. <sm...@rt...> - 2011-02-17 12:45:55
|
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
|
|
From: Jan K. <jan...@we...> - 2011-02-17 08:45:38
|
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 |
|
From: Sebastian S. <sm...@rt...> - 2011-02-16 16:57:40
|
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 |
|
From: Glen W. <gl...@je...> - 2011-02-11 14:19:26
|
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" |
|
From: Glen W. <gl...@je...> - 2011-02-09 20:50:42
|
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" |
|
From: Glen W. <gl...@je...> - 2011-02-09 20:36:20
|
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" |
|
From: Glen W. <gl...@je...> - 2011-02-09 17:11:14
|
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 > |
|
From: Jan K. <jan...@si...> - 2011-02-09 16:59:58
|
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 |
|
From: Glen W. <gl...@je...> - 2011-02-09 16:54:20
|
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 > |
4 messages has been excluded from this view by a project administrator.
