rtnet-developers — development-related list

Re: [RTnet-developers] Ethernet IP

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

On 2011-01-27 18:26, Glen Wernersbach wrote:
> Hi All,
> 
> 
> Well, I am now into my program.
> 
> I have rt_dev_select working and it detects an incoming TCP connection.
> 
> However, when I go to rt_dev_accept(), it returns function not implemented.
> I can it find it use in any RTNET examples.
> 
> Any ideas?

RTAI? Just guessing as it works under Xenomai (via POSIX).

Jan

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

Re: [RTnet-developers] Ethernet IP

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

Hi All,


Well, I am now into my program.

I have rt_dev_select working and it detects an incoming TCP connection.

However, when I go to rt_dev_accept(), it returns function not implemented.
I can it find it use in any RTNET examples.

Any ideas?

Glen

On 1/26/11 3:34 AM, "Jan Kiszka" <jan...@we...> wrote:

> On 2011-01-19 00:48, Glen Wernersbach wrote:
>> Hi All,
>> 
>> Well, I now have script to the point where I an ping non RTNET devices. I am
>> now trying to get my RTNET stack to accept and send TCP and UDP packets
>> from/to non RTNET stack devices.
>> 
>> Again, I am only using RTNET for the real time NIC, UDP and TCP drivers.
>> 
>> The Ethernet IP spec makes use of Administrative scoping broad cast address.
>> To get my program working on non RTNET stack, I have to issue this routing
>> command:
>> route add -net 224.0.0.0 netmask 240.0.0.0 dev eth3
>> 
>> While the actual scope could be less than the command above, do you know how
>> I would do the same command with RTROUTE which has difference syntax.
>> 
> 
> For sending any IP frame to and RTnet segment, you need to specify both
> the destination device ("rtethX") and the destination MAC which is
> FF:FF:FF:FF:FF:FF in this case. However, you can't specify this for a
> complete range of addresses like in the above case, you need to tell the
> precise 224.x.x.x address(es). Network routes are also possible, but
> they are then targeting a specific gateway via its IP.
> 
> More on this in Documentation/README.routing.
> 
> 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

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

On 2011-01-19 00:48, Glen Wernersbach wrote:
> Hi All,
> 
> Well, I now have script to the point where I an ping non RTNET devices. I am
> now trying to get my RTNET stack to accept and send TCP and UDP packets
> from/to non RTNET stack devices.
> 
> Again, I am only using RTNET for the real time NIC, UDP and TCP drivers.
> 
> The Ethernet IP spec makes use of Administrative scoping broad cast address.
> To get my program working on non RTNET stack, I have to issue this routing
> command:
> route add -net 224.0.0.0 netmask 240.0.0.0 dev eth3
> 
> While the actual scope could be less than the command above, do you know how
> I would do the same command with RTROUTE which has difference syntax.
> 

For sending any IP frame to and RTnet segment, you need to specify both
the destination device ("rtethX") and the destination MAC which is
FF:FF:FF:FF:FF:FF in this case. However, you can't specify this for a
complete range of addresses like in the above case, you need to tell the
precise 224.x.x.x address(es). Network routes are also possible, but
they are then targeting a specific gateway via its IP.

More on this in Documentation/README.routing.

Jan

Re: [RTnet-developers] Ethernet IP

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

Hi All,

Well, I now have script to the point where I an ping non RTNET devices. I am
now trying to get my RTNET stack to accept and send TCP and UDP packets
from/to non RTNET stack devices.

Again, I am only using RTNET for the real time NIC, UDP and TCP drivers.

The Ethernet IP spec makes use of Administrative scoping broad cast address.
To get my program working on non RTNET stack, I have to issue this routing
command:
route add -net 224.0.0.0 netmask 240.0.0.0 dev eth3

While the actual scope could be less than the command above, do you know how
I would do the same command with RTROUTE which has difference syntax.


Glen




On 12/2/10 2:52 AM, "Jan Kiszka" <jan...@we...> wrote:

> Am 01.12.2010 23:34, Glen Wernersbach wrote:
>> Hi All,
>> 
>> Back at this. My program now compiles. I think I am loading all the correct
>> libraries to do just NIC, UDP and TCP with RTNET:
>>> insmod /usr/realtime/modules/rtai_hal.ko
>>> insmod /usr/realtime/modules/rtai_lxrt.ko
>>> insmod /usr/realtime/modules/rtai_sem.ko
>>> insmod /usr/realtime/modules/rtai_rtdm.ko
>>> rmmod e1000e
>>> insmod /usr/rtnet/modules/rtnet.ko
>>> insmod /usr/rtnet/modules/rtipv4.ko
>>> insmod /usr/rtnet/modules/rtpacket.ko
>>> insmod /usr/rtnet/modules/rt_loopback.ko
>>> insmod /usr/rtnet/modules/rt_e1000.ko
>>> /usr/src/rtnet-0.9.12/tools/./rtifconfig rteth1 up 192.168.0.2
>>> /usr/src/rtnet-0.9.12/tools/./rtifconfig rtlo up 127.0.0.1
>>> insmod /usr/rtnet/modules/rtudp.ko
>>> insmod /usr/rtnet/modules/rttcp.ko
>>> ./opener 192.168.0.2 255.255.255.0 192.168.0.1 test.com testdevice 00 0E 8C
>>> 9F
>>> 16 09
>> 
>> I current am not connected to a host but am just trying to debug as far as a
>> I can with this just this side. This all works until the last function:
> 
> [ Note that functional debugging is also feasible in QEMU/KVM using e.g.
> the emulated rtl8139. ]
> 
>> 
>>>  /* create a new TCP socket */
>>>   if ((nTCPListener = rt_dev_socket(PF_INET, SOCK_STREAM, 0)) == -1)
>>>     {
>>>       OPENER_TRACE_ERR("error allocating socket stream listener, %d\n",
>>> errno);
>>>       return EIP_ERROR;
>>>     }
>>> 
>>>   /* create a new UDP socket */
>>>   if ((nUDPListener = rt_dev_socket(PF_INET, SOCK_DGRAM, 0)) == -1)
>>>     {
>>>       OPENER_TRACE_ERR("error allocating udp listener socket, %d\n", errno);
>>>       return EIP_ERROR;
>>>     }
>>> 
>>>   my_addr.sin_family = AF_INET;
>>>   my_addr.sin_port = htons(OPENER_ETHERNET_PORT);
>>>   my_addr.sin_addr.s_addr = htonl(INADDR_ANY);
>>>   memset(&my_addr.sin_zero, 0, sizeof(my_addr.sin_zero));
>>> 
>>>   /* bind the new socket to port 0xAF12 (CIP) */
>>>   if ((rt_dev_bind(nTCPListener, (struct sockaddr *) &my_addr, sizeof(struct
>>> sockaddr)))
>>>       == -1)
>>>     {
>>>       OPENER_TRACE_ERR("error with bind: %d %s", errno, strerror(errno));
>>>       return EIP_ERROR;
>>>     }
>>> 
>>>   /* enable the udp socket to receive broadcast messages*/
>>>   y = 1;
>>>   if (0 > rt_dev_setsockopt(nUDPListener, SOL_SOCKET, SO_BROADCAST, &y,
>>> sizeof(int)))
>>>     {
>>>       OPENER_TRACE_ERR("error with setting broadcast receive for udp socket:
>>> %d %s", errno, strerror(errno));
>>>       return EIP_ERROR;
>>>     }
>> 
>> The above function returns ³38  function not implemented²
>> 
>> Do I need to be connected for this to work?
>> 
>> Are my load modules right?
>> 
>> Is this function really not implemented or am I doing something wrong?
>> 
>> If it is not implemented, is there a work around?
> 
> SO_BROADCAST is indeed not implemented. RT-UDP sockets have this feature
> automatically enabled.
> 
> 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"

[RTnet-developers] RTPING

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

Hello All,

I am trying to do a RTNET project which only uses RTNET to keep my  system
in hard real time.

I have setup an RTAI system and installed RTNET. I have added and show an
ethernet card using rtifconfig at my 10.82.88.249 ip address

I can ping this card from a non RTNET system with the ip 10.82.88.250.

I am now trying to ping the 10.82.88.250 non real time system from my
10.82.88.249 RTNET system.

I have 

Now 
-- 
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"

[RTnet-developers] [HEADS UP] Planned copyright clarification of RTnet headers

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

Hi all,

recently some RTnet user was worried again about using RTnet together
with non-GPL compatible applications (typically commercially licensed).
I pointed out what we always stated here:

There is no reason why using RTnet from a non-GPL user space application
should be denied. Also, I do not recall any case where some copyright
holder stated this more restrictively (originally, at least I
considered even certain in-kernel setups OK, but I was still young at
that time ;) ).

However, when looking at the two headers you may need in your user space
application, rtnet.h and sometime also rtmac.h, they do not imply this.
Rather, they are explicitly licensed under GPL v2+. And there is no
other exceptional notice in the RTnet source tree.

In order to finally and clearly express the intended usage model, I
picked up the license exception for headers that you can find in the
Xenomai project, even passed it through the legal department of my
employer and added it tentatively two the mentioned headers. Here is
the diff of rtnet.h, rtmac.h would be extended likewise:

diff --git a/stack/include/rtnet.h b/stack/include/rtnet.h
index 9a325bc..4afa270 100644
--- a/stack/include/rtnet.h
+++ b/stack/include/rtnet.h
@@ -21,6 +21,24 @@
  *  along with this program; if not, write to the Free Software
  *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  *
+ *  As a special exception to the GNU General Public license, the RTnet
+ *  project allows you to use this header file in unmodified form to produce
+ *  application programs executing in user-space which use RTnet services by
+ *  normal system calls. The resulting executable will not be covered by the
+ *  GNU General Public License merely as a result of this header file use.
+ *  Instead, this header file use will be considered normal use of RTnet and
+ *  not a "derived work" in the sense of the GNU General Public License.
+ *
+ *  This exception does not apply when the application code is built as a
+ *  static or dynamically loadable portion of the Linux kernel nor does the
+ *  exception override other reasons justifying application of the GNU General
+ *  Public License.
+ *
+ *  This exception applies only to the code released by the RTnet project
+ *  under the name RTnet and bearing this exception notice. If you copy code
+ *  from other sources into a copy of RTnet, the exception does not apply to
+ *  the code that you add in this way.
+ *
  */
 
 #ifndef __RTNET_H_


I still need to dig through the available logs, identifying the
potentially affected copyright holders. So this is also a public call to
all those who think to own some bits of the affected headers or user
space API. Please state if you agree or disagree with the clarification.

There is no schedule yet when to apply the change. Once the copyright
owner recherche is done, I will define a grace period after which the
change will be applied to give people I'm unable to contact another
chance to reply.

That said, no one already running RTnet aside a commercial application
needs to be concerned. I'm not going to send any lawyer after you, even
if you are using it in a kernel application. However, but that's
nothing new, you should still reconsider your license situation in that
case as there are a few more Linux kernel copyright holders and you may
use more interfaces than just RTnet.

Jan

Re: [RTnet-developers] [PATCH] rt_igb: Add missing ifdefs for CONFIG_PCI_MSI

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

Am 11.01.2011 09:18, Sebastian Smolorz wrote:
> Jan Kiszka wrote:
>> Am 06.01.2011 16:31, Sebastian Smolorz wrote:
>>> When building rt_igb for a kernel without CONFIG_PCI_MSI set the calls
>>> to igb_reset_interrupt_capability() and igb_set_interrupt_capability()
>>> lead to a compilation error because those functions are only known
>>> when CONFIG_PCI_MSI is set to y. Therefore this patch makes the calls
>>> to those functions conditional, too.
>>
>> In fact, the #ifdefs missing here were too much elsewhere. Applied your
>> fix (with cosmetic adjustment) and cleaned up the other spot.
> 
> It does not show up in the repository?

As usual: forgot to push. Fixed.

Jan

Re: [RTnet-developers] [PATCH] rt_igb: Add missing ifdefs for CONFIG_PCI_MSI

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

Jan Kiszka wrote:
> Am 06.01.2011 16:31, Sebastian Smolorz wrote:
> > When building rt_igb for a kernel without CONFIG_PCI_MSI set the calls
> > to igb_reset_interrupt_capability() and igb_set_interrupt_capability()
> > lead to a compilation error because those functions are only known
> > when CONFIG_PCI_MSI is set to y. Therefore this patch makes the calls
> > to those functions conditional, too.
> 
> In fact, the #ifdefs missing here were too much elsewhere. Applied your
> fix (with cosmetic adjustment) and cleaned up the other spot.

It does not show up in the repository?

-- 
Sebastian

Re: [RTnet-developers] [PATCH] rt_igb: Add missing ifdefs for CONFIG_PCI_MSI

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

Am 06.01.2011 16:31, Sebastian Smolorz wrote:
> When building rt_igb for a kernel without CONFIG_PCI_MSI set the calls to
> igb_reset_interrupt_capability() and igb_set_interrupt_capability() lead
> to a compilation error because those functions are only known when
> CONFIG_PCI_MSI is set to y. Therefore this patch makes the calls to those
> functions conditional, too.
> 

In fact, the #ifdefs missing here were too much elsewhere. Applied your
fix (with cosmetic adjustment) and cleaned up the other spot.

Thanks,
Jan

> Signed-off-by: Sebastian Smolorz <sm...@rt...>
> ---
>  drivers/igb/igb_main.c |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/igb/igb_main.c b/drivers/igb/igb_main.c
> index aca794e..2487aeb 100644
> --- a/drivers/igb/igb_main.c
> +++ b/drivers/igb/igb_main.c
> @@ -1568,8 +1568,9 @@ static void __devexit igb_remove(struct pci_dev *pdev)
>  		igb_reset_phy(&adapter->hw);
>  
>  	igb_remove_device(&adapter->hw);
> +#ifdef CONFIG_PCI_MSI
>  	igb_reset_interrupt_capability(adapter);
> -
> +#endif
>  	igb_free_queues(adapter);
>  
>  	rtskb_pool_release(&adapter->skb_pool);
> @@ -1625,8 +1626,9 @@ static int __devinit igb_sw_init(struct igb_adapter *adapter)
>  
>  	/* This call may decrease the number of queues depending on
>  	 * interrupt mode. */
> +#ifdef CONFIG_PCI_MSI
>  	igb_set_interrupt_capability(adapter);
> -
> +#endif
>  	if (igb_alloc_queues(adapter)) {
>  		dev_err(&pdev->dev, "Unable to allocate memory for queues\n");
>  		return -ENOMEM;

[RTnet-developers] [PATCH] rt_igb: Add missing ifdefs for CONFIG_PCI_MSI

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

When building rt_igb for a kernel without CONFIG_PCI_MSI set the calls to
igb_reset_interrupt_capability() and igb_set_interrupt_capability() lead
to a compilation error because those functions are only known when
CONFIG_PCI_MSI is set to y. Therefore this patch makes the calls to those
functions conditional, too.

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

diff --git a/drivers/igb/igb_main.c b/drivers/igb/igb_main.c
index aca794e..2487aeb 100644
--- a/drivers/igb/igb_main.c
+++ b/drivers/igb/igb_main.c
@@ -1568,8 +1568,9 @@ static void __devexit igb_remove(struct pci_dev *pdev)
 		igb_reset_phy(&adapter->hw);
 
 	igb_remove_device(&adapter->hw);
+#ifdef CONFIG_PCI_MSI
 	igb_reset_interrupt_capability(adapter);
-
+#endif
 	igb_free_queues(adapter);
 
 	rtskb_pool_release(&adapter->skb_pool);
@@ -1625,8 +1626,9 @@ static int __devinit igb_sw_init(struct igb_adapter *adapter)
 
 	/* This call may decrease the number of queues depending on
 	 * interrupt mode. */
+#ifdef CONFIG_PCI_MSI
 	igb_set_interrupt_capability(adapter);
-
+#endif
 	if (igb_alloc_queues(adapter)) {
 		dev_err(&pdev->dev, "Unable to allocate memory for queues\n");
 		return -ENOMEM;
-- 
1.7.0.4

Re: [RTnet-developers] Debugging

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

Great stuff thank you.

--
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 Dec 7, 2010, at 12:57 PM, Jan Kiszka <jan...@si...> wrote:

> Am 07.12.2010 18:23, Glen Wernersbach wrote:
>> Jan,
>> 
>> I wanted to follow up on the line below. My understand is that you cannot do
>> hard real time in virtualization.
> 
> That's not true. Nothing conceptually prevents that hypervisor provide
> the same determinism like real hardware. You should just not expect to
> see the same latencies. In practice, not every hypervisor is designed
> for hard or even just soft RT, just like not every OS provides this.
> 
> So far, QEMU/KVM is not capable of providing hard guarantees, and it
> even has problems with soft RT unless you very carefully tune
> everything. However, last time I tried I was able to measure << 1 ms
> guest user space latencies in a PREEEMPT-RT or Xenomai on PREEMPT-RT
> with KVM setup (modern AMD host). And that's an order of magnitude where
> quite a few real applications start to be happy.
> 
>> You seem to indicate we can debug our
>> RTNET app to some extend using QEMU and KVM.
>> 
>> Just wonder what you experience was?
> 
> It depends on what aspects of your app, middleware, driver you want to
> debug and how they react if deadlines are missed. If they jump out of
> the window because some operation took surprisingly long, then you
> either need to avoid this code path or relax the check when running in a
> VM. That's fairly easy with new code, but it can be hairy if not
> impossible with existing large projects.
> 
> Transferred to RTnet: I'm able to run a full-featured network
> (RTmac/TDMA, RTcfg) in multiple VMs with moderate cycles. Of course,
> deadlines will be missed all the time whenever the host is overloaded or
> just temporarily busy with other work. But a lot of tests are
> nevertheless possible.
> 
> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
> 

Re: [RTnet-developers] Debugging

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

Am 07.12.2010 18:23, Glen Wernersbach wrote:
> Jan,
> 
> I wanted to follow up on the line below. My understand is that you cannot do
> hard real time in virtualization.

That's not true. Nothing conceptually prevents that hypervisor provide
the same determinism like real hardware. You should just not expect to
see the same latencies. In practice, not every hypervisor is designed
for hard or even just soft RT, just like not every OS provides this.

So far, QEMU/KVM is not capable of providing hard guarantees, and it
even has problems with soft RT unless you very carefully tune
everything. However, last time I tried I was able to measure << 1 ms
guest user space latencies in a PREEEMPT-RT or Xenomai on PREEMPT-RT
with KVM setup (modern AMD host). And that's an order of magnitude where
quite a few real applications start to be happy.

> You seem to indicate we can debug our
> RTNET app to some extend using QEMU and KVM.
> 
> Just wonder what you experience was?

It depends on what aspects of your app, middleware, driver you want to
debug and how they react if deadlines are missed. If they jump out of
the window because some operation took surprisingly long, then you
either need to avoid this code path or relax the check when running in a
VM. That's fairly easy with new code, but it can be hairy if not
impossible with existing large projects.

Transferred to RTnet: I'm able to run a full-featured network
(RTmac/TDMA, RTcfg) in multiple VMs with moderate cycles. Of course,
deadlines will be missed all the time whenever the host is overloaded or
just temporarily busy with other work. But a lot of tests are
nevertheless possible.

Jan

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

Re: [RTnet-developers] RTnet hangs system when brought up with heavy traffic

[Anders B. <and...@co...>]

On 12/07/2010 06:35 PM, Jan Kiszka wrote:
> Am 07.12.2010 18:21, Anders Blomdell wrote:
>> If I do 'rtifconfig rteth0 up' on a network with heavy broadcast traffic
>> (which I later intend to catch/throw away), the system does a hard
>> lockup after a few lines like these:
>>
>>    'RTnet: no one cared for packet with layer 3 protocol type ...'
>>
>> I would humbly suggest something like the attached patch.
>
> Rate-limiting this warning makes sense as RTnet is also used in soft-RT
> scenarios on open networks.
>
> But I would prefer having some rtdm_printk_ratelimted similar to what
> Linux provides. That means: extend RTDM this way and then use it here.
> Yeah, a bit more work. Would you look into this?
Probably not before early next year since I have a pressing deadline and 
have spent more time than expected to chase bugs. After that (or if I 
find some idle time while waiting for compilations), yes.

/Anders



-- 
Anders Blomdell                  Email: and...@co...
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

Re: [RTnet-developers] RTnet hangs system when brought up with heavy traffic

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

Am 07.12.2010 18:21, Anders Blomdell wrote:
> If I do 'rtifconfig rteth0 up' on a network with heavy broadcast traffic
> (which I later intend to catch/throw away), the system does a hard
> lockup after a few lines like these:
> 
>   'RTnet: no one cared for packet with layer 3 protocol type ...'
> 
> I would humbly suggest something like the attached patch.

Rate-limiting this warning makes sense as RTnet is also used in soft-RT
scenarios on open networks.

But I would prefer having some rtdm_printk_ratelimted similar to what
Linux provides. That means: extend RTDM this way and then use it here.
Yeah, a bit more work. Would you look into this?

Thanks,
Jan

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

[RTnet-developers] Debugging

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

Jan,

I wanted to follow up on the line below. My understand is that you cannot do
hard real time in virtualization. You seem to indicate we can debug our
RTNET app to some extend using QEMU and KVM.

Just wonder what you experience was?

Glen


On 12/2/10 2:52 AM, "Jan Kiszka" <jan...@we...> wrote:

> [ Note that functional debugging is also feasible in QEMU/KVM using e.g.
> the emulated rtl8139. ]

-- 
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"

[RTnet-developers] RTnet hangs system when brought up with heavy traffic

[Anders B. <and...@co...>]

If I do 'rtifconfig rteth0 up' on a network with heavy broadcast traffic 
(which I later intend to catch/throw away), the system does a hard 
lockup after a few lines like these:

   'RTnet: no one cared for packet with layer 3 protocol type ...'

I would humbly suggest something like the attached patch.

Regards

Anders Blomdell

-- 
Anders Blomdell                  Email: and...@co...
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

Re: [RTnet-developers] Ethernet IP

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

Am 02.12.2010 15:09, Glen Wernersbach wrote:
> So I cab ignore the error.
> 
> In the future for compatibility reasons, you may want to return successful in there cases.

Not without actually implementing the logic behind it. Patches always
welcome.

Jan

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

Re: [RTnet-developers] Ethernet IP

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

So I cab ignore the error.

In the future for compatibility reasons, you may want to return successful in there cases.

--
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 Dec 2, 2010, at 2:52 AM, Jan Kiszka <jan...@we...> wrote:

> Am 01.12.2010 23:34, Glen Wernersbach wrote:
>> Hi All,
>> 
>> Back at this. My program now compiles. I think I am loading all the correct
>> libraries to do just NIC, UDP and TCP with RTNET:
>>> insmod /usr/realtime/modules/rtai_hal.ko
>>> insmod /usr/realtime/modules/rtai_lxrt.ko
>>> insmod /usr/realtime/modules/rtai_sem.ko
>>> insmod /usr/realtime/modules/rtai_rtdm.ko
>>> rmmod e1000e
>>> insmod /usr/rtnet/modules/rtnet.ko
>>> insmod /usr/rtnet/modules/rtipv4.ko
>>> insmod /usr/rtnet/modules/rtpacket.ko
>>> insmod /usr/rtnet/modules/rt_loopback.ko
>>> insmod /usr/rtnet/modules/rt_e1000.ko
>>> /usr/src/rtnet-0.9.12/tools/./rtifconfig rteth1 up 192.168.0.2
>>> /usr/src/rtnet-0.9.12/tools/./rtifconfig rtlo up 127.0.0.1
>>> insmod /usr/rtnet/modules/rtudp.ko
>>> insmod /usr/rtnet/modules/rttcp.ko
>>> ./opener 192.168.0.2 255.255.255.0 192.168.0.1 test.com testdevice 00 0E 8C 9F
>>> 16 09
>> 
>> I current am not connected to a host but am just trying to debug as far as a
>> I can with this just this side. This all works until the last function:
> 
> [ Note that functional debugging is also feasible in QEMU/KVM using e.g.
> the emulated rtl8139. ]
> 
>> 
>>> /* create a new TCP socket */
>>>  if ((nTCPListener = rt_dev_socket(PF_INET, SOCK_STREAM, 0)) == -1)
>>>    {
>>>      OPENER_TRACE_ERR("error allocating socket stream listener, %d\n",
>>> errno);
>>>      return EIP_ERROR;
>>>    }
>>> 
>>>  /* create a new UDP socket */
>>>  if ((nUDPListener = rt_dev_socket(PF_INET, SOCK_DGRAM, 0)) == -1)
>>>    {
>>>      OPENER_TRACE_ERR("error allocating udp listener socket, %d\n", errno);
>>>      return EIP_ERROR;
>>>    }
>>> 
>>>  my_addr.sin_family = AF_INET;
>>>  my_addr.sin_port = htons(OPENER_ETHERNET_PORT);
>>>  my_addr.sin_addr.s_addr = htonl(INADDR_ANY);
>>>  memset(&my_addr.sin_zero, 0, sizeof(my_addr.sin_zero));
>>> 
>>>  /* bind the new socket to port 0xAF12 (CIP) */
>>>  if ((rt_dev_bind(nTCPListener, (struct sockaddr *) &my_addr, sizeof(struct
>>> sockaddr)))
>>>      == -1)
>>>    {
>>>      OPENER_TRACE_ERR("error with bind: %d %s", errno, strerror(errno));
>>>      return EIP_ERROR;
>>>    }
>>> 
>>>  /* enable the udp socket to receive broadcast messages*/
>>>  y = 1;
>>>  if (0 > rt_dev_setsockopt(nUDPListener, SOL_SOCKET, SO_BROADCAST, &y,
>>> sizeof(int)))
>>>    {
>>>      OPENER_TRACE_ERR("error with setting broadcast receive for udp socket:
>>> %d %s", errno, strerror(errno));
>>>      return EIP_ERROR;
>>>    }
>> 
>> The above function returns ³38  function not implemented²
>> 
>> Do I need to be connected for this to work?
>> 
>> Are my load modules right?
>> 
>> Is this function really not implemented or am I doing something wrong?
>> 
>> If it is not implemented, is there a work around?
> 
> SO_BROADCAST is indeed not implemented. RT-UDP sockets have this feature
> automatically enabled.
> 
> Jan
> 

Re: [RTnet-developers] Ethernet IP

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

Am 01.12.2010 23:34, Glen Wernersbach wrote:
> Hi All,
> 
> Back at this. My program now compiles. I think I am loading all the correct
> libraries to do just NIC, UDP and TCP with RTNET:
>> insmod /usr/realtime/modules/rtai_hal.ko
>> insmod /usr/realtime/modules/rtai_lxrt.ko
>> insmod /usr/realtime/modules/rtai_sem.ko
>> insmod /usr/realtime/modules/rtai_rtdm.ko
>> rmmod e1000e
>> insmod /usr/rtnet/modules/rtnet.ko
>> insmod /usr/rtnet/modules/rtipv4.ko
>> insmod /usr/rtnet/modules/rtpacket.ko
>> insmod /usr/rtnet/modules/rt_loopback.ko
>> insmod /usr/rtnet/modules/rt_e1000.ko
>> /usr/src/rtnet-0.9.12/tools/./rtifconfig rteth1 up 192.168.0.2
>> /usr/src/rtnet-0.9.12/tools/./rtifconfig rtlo up 127.0.0.1
>> insmod /usr/rtnet/modules/rtudp.ko
>> insmod /usr/rtnet/modules/rttcp.ko
>> ./opener 192.168.0.2 255.255.255.0 192.168.0.1 test.com testdevice 00 0E 8C 9F
>> 16 09
> 
> I current am not connected to a host but am just trying to debug as far as a
> I can with this just this side. This all works until the last function:

[ Note that functional debugging is also feasible in QEMU/KVM using e.g.
the emulated rtl8139. ]

> 
>>  /* create a new TCP socket */
>>   if ((nTCPListener = rt_dev_socket(PF_INET, SOCK_STREAM, 0)) == -1)
>>     {
>>       OPENER_TRACE_ERR("error allocating socket stream listener, %d\n",
>> errno);
>>       return EIP_ERROR;
>>     }
>>
>>   /* create a new UDP socket */
>>   if ((nUDPListener = rt_dev_socket(PF_INET, SOCK_DGRAM, 0)) == -1)
>>     {
>>       OPENER_TRACE_ERR("error allocating udp listener socket, %d\n", errno);
>>       return EIP_ERROR;
>>     }
>>
>>   my_addr.sin_family = AF_INET;
>>   my_addr.sin_port = htons(OPENER_ETHERNET_PORT);
>>   my_addr.sin_addr.s_addr = htonl(INADDR_ANY);
>>   memset(&my_addr.sin_zero, 0, sizeof(my_addr.sin_zero));
>>
>>   /* bind the new socket to port 0xAF12 (CIP) */
>>   if ((rt_dev_bind(nTCPListener, (struct sockaddr *) &my_addr, sizeof(struct
>> sockaddr)))
>>       == -1)
>>     {
>>       OPENER_TRACE_ERR("error with bind: %d %s", errno, strerror(errno));
>>       return EIP_ERROR;
>>     }
>>
>>   /* enable the udp socket to receive broadcast messages*/
>>   y = 1;
>>   if (0 > rt_dev_setsockopt(nUDPListener, SOL_SOCKET, SO_BROADCAST, &y,
>> sizeof(int)))
>>     {
>>       OPENER_TRACE_ERR("error with setting broadcast receive for udp socket:
>> %d %s", errno, strerror(errno));
>>       return EIP_ERROR;
>>     }
> 
> The above function returns ³38  function not implemented²
> 
> Do I need to be connected for this to work?
> 
> Are my load modules right?
> 
> Is this function really not implemented or am I doing something wrong?
> 
> If it is not implemented, is there a work around?

SO_BROADCAST is indeed not implemented. RT-UDP sockets have this feature
automatically enabled.

Jan

Re: [RTnet-developers] Potential problem with rt_eepro100

[Anders B. <and...@co...>]

Jan Kiszka wrote:
> Am 28.10.2010 11:34, Anders Blomdell wrote:
>> Jan Kiszka wrote:
>>> Am 28.10.2010 09:34, Anders Blomdell wrote:
>>>> Anders Blomdell wrote:
>>>>> Anders Blomdell wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm trying to use rt_eepro100, for sending raw ethernet packets,
>>>>>> but I'm
>>>>>> experincing occasionally weird behaviour.
>>>>>>
>>>>>> Versions of things:
>>>>>>
>>>>>>   linux-2.6.34.5
>>>>>>   xenomai-2.5.5.2
>>>>>>   rtnet-39f7fcf
>>>>>>
>>>>>> The testprogram runs on two computers with "Intel Corporation
>>>>>> 82557/8/9/0/1 Ethernet Pro 100 (rev 08)" controller, where one
>>>>>> computer
>>>>>> acts as a mirror sending back packets received from the ethernet (only
>>>>>> those two computers on the network), and the other sends packets and
>>>>>> measures roundtrip time. Most packets comes back in approximately 100
>>>>>> us, but occasionally the reception times out (once in about 100000
>>>>>> packets or more), but the packets gets immediately received when
>>>>>> reception is retried, which might indicate a race between
>>>>>> rt_dev_recvmsg
>>>>>> and interrupt, but I might miss something obvious.
>>>>> Changing one of the ethernet cards to a "Intel Corporation 82541PI
>>>>> Gigabit Ethernet Controller (rev 05)", while keeping everything else
>>>>> constant, changes behavior somewhat; after receiving a few 100000
>>>>> packets, reception stops entirely (-EAGAIN is returned), while
>>>>> transmission proceeds as it should (and mirror returns packets).
>>>>>
>>>>> Any suggestions on what to try?
>>>> Since the problem disappears with 'maxcpus=1', I suspect I have a SMP
>>>> issue (machine is a Core2 Quad), so I'll move to xenomai-core.
>>>> (original message can be found at
>>>> http://sourceforge.net/mailarchive/message.php?msg_name=4CC82C8D.3080808%40control.lth.se
>>>> )
>>>>
>>>> Xenomai-core gurus: which is the corrrect way to debug SMP issues?
>>>> Can I run I-pipe-tracer and expect to be able save at least 150 us of
>>>> traces for all cpus? Any hints/suggestions/insigths are welcome...
>>> The i-pipe tracer unfortunately only saves traces for a the CPU that
>>> triggered the freeze. To have a full pictures, you may want to try my
>>> ftrace port I posted recently for 2.6.35.
>> 2.6.35.7 ?
Well, 2.6.35.7/xenomai/rtnet without ftrace patch freezes after approx 
8000 rounds (16000 packets). Time freshen up find serial port console 
debugging I guess (under the assumption that this is the same bug, but 
easier to reproduce).

/Anders

Re: [RTnet-developers] [RTnet-users] Potential problem with rt_eepro100

[Anders B. <and...@co...>]

Jan Kiszka wrote:
> Am 28.10.2010 09:34, Anders Blomdell wrote:
>> Anders Blomdell wrote:
>>> Anders Blomdell wrote:
>>>> Hi,
>>>>
>>>> I'm trying to use rt_eepro100, for sending raw ethernet packets, but I'm
>>>> experincing occasionally weird behaviour.
>>>>
>>>> Versions of things:
>>>>
>>>>   linux-2.6.34.5
>>>>   xenomai-2.5.5.2
>>>>   rtnet-39f7fcf
>>>>
>>>> The testprogram runs on two computers with "Intel Corporation
>>>> 82557/8/9/0/1 Ethernet Pro 100 (rev 08)" controller, where one computer
>>>> acts as a mirror sending back packets received from the ethernet (only
>>>> those two computers on the network), and the other sends packets and
>>>> measures roundtrip time. Most packets comes back in approximately 100
>>>> us, but occasionally the reception times out (once in about 100000
>>>> packets or more), but the packets gets immediately received when
>>>> reception is retried, which might indicate a race between rt_dev_recvmsg
>>>> and interrupt, but I might miss something obvious.
>>> Changing one of the ethernet cards to a "Intel Corporation 82541PI 
>>> Gigabit Ethernet Controller (rev 05)", while keeping everything else 
>>> constant, changes behavior somewhat; after receiving a few 100000 
>>> packets, reception stops entirely (-EAGAIN is returned), while 
>>> transmission proceeds as it should (and mirror returns packets).
>>>
>>> Any suggestions on what to try?
>> Since the problem disappears with 'maxcpus=1', I suspect I have a SMP 
>> issue (machine is a Core2 Quad), so I'll move to xenomai-core.
>> (original message can be found at 
>> http://sourceforge.net/mailarchive/message.php?msg_name=4CC82C8D.3080808%40control.lth.se 
>> )
>>
>> Xenomai-core gurus: which is the corrrect way to debug SMP issues?
>> Can I run I-pipe-tracer and expect to be able save at least 150 us of 
>> traces for all cpus? Any hints/suggestions/insigths are welcome...
> 
> The i-pipe tracer unfortunately only saves traces for a the CPU that
> triggered the freeze. To have a full pictures, you may want to try my
> ftrace port I posted recently for 2.6.35.
2.6.35.7 ?

/Anders

Re: [RTnet-developers] [RTnet-users] Potential problem with rt_eepro100

[Anders B. <and...@co...>]

Anders Blomdell wrote:
> Anders Blomdell wrote:
>> Hi,
>>
>> I'm trying to use rt_eepro100, for sending raw ethernet packets, but I'm
>> experincing occasionally weird behaviour.
>>
>> Versions of things:
>>
>>   linux-2.6.34.5
>>   xenomai-2.5.5.2
>>   rtnet-39f7fcf
>>
>> The testprogram runs on two computers with "Intel Corporation
>> 82557/8/9/0/1 Ethernet Pro 100 (rev 08)" controller, where one computer
>> acts as a mirror sending back packets received from the ethernet (only
>> those two computers on the network), and the other sends packets and
>> measures roundtrip time. Most packets comes back in approximately 100
>> us, but occasionally the reception times out (once in about 100000
>> packets or more), but the packets gets immediately received when
>> reception is retried, which might indicate a race between rt_dev_recvmsg
>> and interrupt, but I might miss something obvious.
> 
> Changing one of the ethernet cards to a "Intel Corporation 82541PI 
> Gigabit Ethernet Controller (rev 05)", while keeping everything else 
> constant, changes behavior somewhat; after receiving a few 100000 
> packets, reception stops entirely (-EAGAIN is returned), while 
> transmission proceeds as it should (and mirror returns packets).
> 
> Any suggestions on what to try?

Since the problem disappears with 'maxcpus=1', I suspect I have a SMP 
issue (machine is a Core2 Quad), so I'll move to xenomai-core.
(original message can be found at 
http://sourceforge.net/mailarchive/message.php?msg_name=4CC82C8D.3080808%40control.lth.se 
)

Xenomai-core gurus: which is the corrrect way to debug SMP issues?
Can I run I-pipe-tracer and expect to be able save at least 150 us of 
traces for all cpus? Any hints/suggestions/insigths are welcome...

Regards

Anders Blomdell

Re: [RTnet-developers] DO_DIV

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

Am 26.10.2010 17:35, Glen Wernersbach wrote:
> I am doing my first project of RTNET on RTAI.
> 
> My first problem when I try to compile the example, I get an error for the
> do_div function in the LXRT include. It appears to be some about the ASM
> function. I am sure I need to add a header or compile option.Any quick
> answer?
> 
> 
> Also, is there a RT_DEV_SELECTION() now in RTAI?
> 

My strong suspect is that this is a pure RTDM-for-RTAI wrapping issue,
try reporting it to their list. But without even attaching the errors
you get and describing the configuration steps you did, hardly anyone
will be able to help you.

Jan

[RTnet-developers] DO_DIV

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

I am doing my first project of RTNET on RTAI.

My first problem when I try to compile the example, I get an error for the
do_div function in the LXRT include. It appears to be some about the ASM
function. I am sure I need to add a header or compile option.Any quick
answer?


Also, is there a RT_DEV_SELECTION() now in RTAI?


-- 
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] Patch to compile rtnet with 2.6.35.7

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

Am 20.10.2010 17:33, Anders Blomdell wrote:
> This patch together with
> 
> http://rtnet.git.sourceforge.net/git/gitweb.cgi?p=rtnet/rtnet;a=commit;h=fc574959b590e001357fcfb8bfb2853571c0ec14
> http://rtnet.git.sourceforge.net/git/gitweb.cgi?p=rtnet/rtnet;a=commit;h=a914a3ed980a74d9e97a3c438b10eebd2ca6c2ec
> 
> has made it possible to compile rtnet-0.9.12 with linux-2.6.35.7 and
> xenomai-2.5.5.2 and latest ipipe.

Thanks - really just a few minutes too late: I ripped out the breaking
code, see git head. It was unused anyway.

Jan